Re: LyX 2.4.0 Alpha 3

[Liviu Andronic]

On 2/19/21, Richard Kimberly Heck  wrote:
> A third alpha of LyX 2.4.0 has now been released. It can be found here:
>
> http://ftp.lyx.org/ftp/pub/lyx/devel/lyx-2.4/
>

Ubuntu packages are available on the testing PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily


Liviu


> As usual with alpha software, this is released for testing purposes
> only. Although many of us have been using it regularly, and it seems to
> be fairly stable, nasty surprises are always a possibility.
>
> One of those, which more or less prevented Alpha 2 from working on
> Windows, should now have been fixed.
>
> If you run into any problems, please report them either on the lyx-devel
> mailing list or on our bug tracker:
>
> https://www.lyx.org/trac/wiki/BugTrackerHome
>
> Riki
>
>
> --
> lyx-users mailing list
> lyx-us...@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-users
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4 Alpha 2

[Liviu Andronic]

On 2/8/21, Richard Kimberly Heck  wrote:
> The LyX team is pleased to announce the release of the second alpha for
> LyX 2.4. You can dowload it here:
>
> http://ftp.lyx.org/ftp/pub/lyx/devel/lyx-2.4/
>

For Ubuntu testers alpha2 packages are available on the 'Development' PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

The installation of the 'lyx2.4pre' pre-release packages is
independent of the stable 'lyx' installation, so you can have the
pre-release and stable packages installed side-by-side. They shouldn't
interfere with each other.

Please report if you have any issues with the packages.

Liviu


> For some information about the new features, see:
>
> https://wiki.lyx.org/LyX/NewInLyX24
>
> Please note that, as alpha software, there may be some nasty bugs
> lurking. LyX 2.4 alpha 2 is released for testing only. That said, we
> really would appreciate testing, especially on Windows, where we have
> few active developers.
>
> Riki
>
>
> --
> lyx-users mailing list
> lyx-us...@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-users
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4.0-alpha1

[Liviu Andronic]

On 1/31/21, José Abílio Matos  wrote:
> On Sunday, January 31, 2021 12:12:41 PM WET Enrico Forestieri wrote:
>> Does the attached patch work for you?
>
> Yes. Without the patch "make check" fails, with the patch it works.
>

Thanks José and Enrico for looking into this. I can confirm that the
patch fixes compilation on Ubuntu as well.

Liviu
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4.0-alpha1

[Liviu Andronic]

On 1/31/21, José Abílio Matos  wrote:
> On Sunday, January 31, 2021 12:12:41 PM WET Enrico Forestieri wrote:
>> Does the attached patch work for you?
>
> Yes. Without the patch "make check" fails, with the patch it works.
>

Thanks José and Enrico for looking into this. I can confirm that the
patch fixes compilation on Ubuntu as well.

Liviu
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4.0-alpha1

[Liviu Andronic]

Hi all,

On 12/29/20, Richard Kimberly Heck  wrote:
> I've built tarballs for LyX 2.4.0-alpha1 and placed them here:
>
> http://ftp.lyx.org/ftp/pub/lyx/devel/lyx-2.4/
>

I've tried building Alpha 1 on Bionic but compilation ends up with this error:

g++ -fPIC -O2 -std=c++17  -std=c++17  -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security   -Wl,-z,defs -Wl,--as-needed
-Wl,-Bsymbolic-functions -Wl,-z,relro -o check_convert
tests/check_convert.o tests/dummy_functions.o tests/boost.o
liblyxsupport.a  -lQt5Core  -lmythes-1.2 -laspell  -lmagic
/usr/bin/ld: liblyxsupport.a(checksum.o): undefined reference to symbol 'crc32'
//lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing
from command line
collect2: error: ld returned 1 exit status

Here's the complete build log:
https://launchpadlibrarian.net/519618154/buildlog_ubuntu-bionic-amd64.lyx2.4pre_2.4.0~alpha1-1~bionic~ppa1_BUILDING.txt.gz


Any idea what's wrong? I'm not sure if maybe there are some new
dependencies for 2.4 I should take into account or if maybe a specific
compiler flag is needed.


Thank you,
Liviu



> Please prepare binaries. Sorry for doing this right on top of 2.3.6.1,
> but it seemed worth doing while I had a few moments!
>
> Further info to come on moves toward 2.4.0.
>
> Riki
>
>
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.3.6.1 Tarballs and Binaries

[Liviu Andronic]

On 12/29/20, Richard Kimberly Heck  wrote:
> The fix for bug #12056, which prevented inclusion of TeX files, warrants
> a quick re-release. I've also included the fix for #11746, which caused
> problems on Gnome Wayland on Fedora.
>
> Tarballs here:
>
> http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/
>
> Please prepare binaries.
>

Ubuntu packages now uploaded to the PPA.

Liviu


> Riki
>
>
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [ANNOUNCE] LyX 2.3.4.2 'Emergency' Release

[Liviu Andronic]

On 2/11/20, Richard Kimberly Heck  wrote:
>
> This is an emergency release that fixes four bugs in 2.3.4. Only the
> first two really warrant an emergency release, but while we're at it...
>
Ubuntu packages are now available on the PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/release


Liviu


> The first, bug #11728, caused a five-second delay when attempting
> to save files on Windows. This was a side effect of the fix for #10091
> and reminds us why it would be good to have more testing on Windows.
>
> The second bug is discussed in this thread
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg210294.html
> and concerns a crash related to the math toolbar. This was due to an
> uninitialize buffer_ member revealed by the fix for #11586.
>
> The third, bug #11724, affects Beamer presentations and causes bad output
> when page geometry is set in certain ways. LyX should and how does ignore
> such settings.
>
> The last, bug #11579, is an old one, but a serious one, that prevents
> the use of CJKUtf8 in ERT. It's a straightforward fix for a bug that is
> pretty serious for people who encounter it.
>
> All LyX users are encouraged to upgrade to 2.3.4.2.
>
> --
> lyx-users mailing list
> lyx-us...@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-users
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics

[Liviu Andronic]

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: Ubuntu packages?

[Liviu Andronic]

Hi Scott,
Thanks for the reminder.

The packages are now uploaded on the PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/release

Please let me know if you encounter any issues with them. Regards,
Liviu


On 10/1/18, Scott Kostyshak  wrote:
> On Mon, Oct 01, 2018 at 09:59:01AM -0400, Paul A. Rubin wrote:
> I think he is just very busy. Let's CC him and see if he has an estimate
> of when he can update the PPA.
>
> Liviu, in the future would it help if we send you an email when a new
> version of LyX is released? Or perhaps it would be better if we sent you
> an email a week (two weeks?) before a planned release?
>
> Thanks,
>
> Scott
>

Re: LyX 2.3.0 Released

[Liviu Andronic]

On 3/16/18, Scott Kostyshak  wrote:
> Public release of LyX version 2.3.0
> 
>

Ubuntu packages are now available on the PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/release


Regards,
Liviu


> We are proud to announce the release of LyX 2.3.0.
>
> With this release, LyX celebrates 22 years of existence. The 2.3 series
> has a rich set of new features compared to the current stable series.
>
> LyX 2.3.0 is the culmination of two years of hard work. An overview
> of the new features can be found here:
>   https://wiki.lyx.org/LyX/NewInLyX23
>
> You can download LyX 2.3.0 from https://www.lyx.org/Download/.
> Unfortunately, official Windows binaries are not available at this time.
>
> We hope you will enjoy the result!
>
> If a file from an earlier version of LyX is opened *and saved* with
> any version of 2.3.x, then the original file will automatically be
> backed up. The backup file will be found in the backup directory, if one
> is set under Tools> Preferences> Paths, or else in the same folder as
> the original file, if no backup directory is set. The filename of the
> backup file will be:
> ORIGNAME-lyxformat-NUM.lyx~
> where NUM is the LyX format number of the original file. In the case of
> a 2.2.x file, this will be 508, but in the case of older files it will be
> different.
>
> The file lib/RELEASE-NOTES lists some known issues and problems compared
> to the current stable releases (LyX 2.2.x). We strongly recommend that
> packagers of LyX on various platforms and distributions read this file.
>
> As with any major release, this one comes with a lot of new features but
> also some bugs. If you think you have found a bug in LyX 2.3.0, either
> email the LyX developers' mailing list (lyx-devel at lists.lyx.org),
> or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome .
> Please specify if the behavior you are reporting is different from behavior
> in a previous LyX version.
>
> If you have trouble using LyX or have a question, consult the
> documentation that comes with LyX (under Help) and the LyX wiki, which you
> will find at https://wiki.lyx.org/. You can also send email to the LyX
> users'
> list (lyx-users at lists.lyx.org).
>
> The LyX team.
> https://www.lyx.org
>
>

Re: LyX version 2.3.0rc2 available

[Liviu Andronic]

On 1/30/18, Scott Kostyshak  wrote:
> Public release of LyX version 2.3.0rc2
> 
>

Ubuntu packages are now available on the PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily


Regards,
Liviu


> We are proud to announce the second public release candidate of the new LyX
> 2.3
> series. This pre-release is meant for testing and should not be used for
> serious work. For curious users who would like to test in order to help
> catch
> bugs before the 2.3.0 release, please back up all of your documents and be
> prepared for the worst to happen. Most users (who desire a stable LyX
> version)
> should not use this pre-release.
>
> The 2.3 series has a rich set of new features compared to the current
> stable
> series. An overview of the new features can be found here:
>
>   https://wiki.lyx.org/LyX/NewInLyX23
>
> You can download LyX 2.3.0rc2 from ftp://ftp.lyx.org/pub/lyx/devel/.
>
> We appreciate your help in testing this pre-release!
>
> If a file from an earlier version of LyX is opened *and saved* with
> any version of 2.3.x, then the original file will automatically be
> backed up. The backup file will be found in the backup directory, if one
> is set under Tools> Preferences> Paths, or else in the same folder as
> the original file, if no backup directory is set. The filename of the
> backup file will be:
> ORIGNAME-lyxformat-NUM.lyx~
> where NUM is the LyX format number of the original file. In the case of
> 2.2.x file, this will be 508, but in the case of older files it will be
> different.
>
> The file lib/RELEASE-NOTES lists some known issues and problems compared
> to the current stable releases (LyX 2.2.x). We strongly recommend that
> packagers of LyX on various platforms and distributions read this file.
>
> As with any major release, this one comes with a lot of new features but
> also some bugs. If you think you have found a bug in LyX 2.3.0rc2, either
> email the LyX developers' mailing list (lyx-devel at lists.lyx.org),
> or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome.
> Please specify if the behavior you are reporting is different from behavior
> in a previous LyX version.
>
> If you have trouble using LyX or have a question, consult the
> documentation that comes with LyX (under Help) and the LyX wiki, which you
> will find at https://wiki.lyx.org/. You can also send email to the LyX
> users'
> list (lyx-users at lists.lyx.org).
>
> The LyX team.
> https://www.lyx.org
>
>

Re: LyX version 2.3.0rc1 available

[Liviu Andronic]

On 12/17/17, Scott Kostyshak  wrote:
> Public release of LyX version 2.3.0rc1
> 
>

A bit late but Ubuntu packages for RC1 are now available on the devel PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

Regards,
Liviu


> We are proud to announce the first public release candidate of the new LyX
> 2.3
> series. This first release candidate was actually available more than a
> month
> ago, but because of problems with our mailing lists we could not officially
> announce it. There have been many changes since then, and we are now moving
> towards a second release candidate.
>
> Please also note that macOS 10.8 is no longer supported (due to our move to
> Qt 5.9.x).
>
> This pre-release is meant for testing and should not be used for serious
> work.
> For curious users who would like to test in order to help catch bugs before
> the 2.3.0 release, please back up all of your documents and be prepared for
> the worst to happen. Most users (who desire a stable LyX version) should
> not
> use this pre-release.
>
> The 2.3 series has a rich set of new features compared to the current
> stable
> series. An overview of the new features can be found here:
>
>   https://wiki.lyx.org/LyX/NewInLyX23
>
> You can download LyX 2.3.0rc1 from ftp://ftp.lyx.org/pub/lyx/devel/.
>
> We appreciate your help in testing this pre-release!
>
> If a file from an earlier version of LyX is opened *and saved* with
> any version of 2.3.x, then the original file will automatically be
> backed up. The backup file will be found in the backup directory, if one
> is set under Tools> Preferences> Paths, or else in the same folder as
> the original file, if no backup directory is set. The filename of the
> backup file will be:
> ORIGNAME-lyxformat-NUM.lyx~
> where NUM is the LyX format number of the original file. In the case of
> 2.2.x file, this will be 508, but in the case of older files it will be
> different.
>
> The file lib/RELEASE-NOTES lists some known issues and problems compared
> to the current stable releases (LyX 2.2.x). We strongly recommend that
> packagers of LyX on various platforms and distributions read this file.
>
> As with any major release, this one comes with a lot of new features but
> also some bugs. If you think you have found a bug in LyX 2.3.0rc1, either
> email the LyX developers' mailing list (lyx-devel at lists.lyx.org),
> or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome.
> Please specify if the behavior you are reporting is different from behavior
> in a previous LyX version.
>
> If you have trouble using LyX or have a question, consult the
> documentation that comes with LyX (under Help) and the LyX wiki, which you
> will find at https://wiki.lyx.org/. You can also send email to the LyX
> users'
> list (lyx-users at lists.lyx.org).
>
> The LyX team.
> https://www.lyx.org
>
>

Re: LyX version 2.3.0 (beta 1)

[Liviu Andronic]

On Thu, Aug 17, 2017 at 8:25 PM, Scott Kostyshak  wrote:

> Public release of LyX version 2.3.0beta1
> 
>
>
Ubuntu 'lyx2.3pre' packages are now available on the Development PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

The packages install independently of your existing stable 2.2.x
installation.

Regards,
Liviu



> We are proud to announce the first public beta of the new LyX 2.3 series.
> This pre-release is meant for testing and should not be used for serious
> work.
> For curious users who would like to test in order to help catch bugs before
> the 2.3.0 release, please back up all of your documents and be prepared for
> the worst to happen. Most users (who desire a stable LyX version) should
> not
> use this pre-release.
>
> The 2.3 series has a rich set of new features compared to the current
> stable
> series. An overview of the new features can be found here:
>
>   http://wiki.lyx.org/LyX/NewInLyX23
>
> You can download LyX 2.3.0beta1 from ftp://ftp.lyx.org/pub/lyx/devel/.
>
> We appreciate your help in testing this pre-release!
>
> The file lib/RELEASE-NOTES lists some known issues and problems compared
> to the current stable releases (LyX 2.2.x). We strongly recommend that
> packagers of LyX on various platforms and distributions read this file.
>
> As with any major release, this one comes with a lot of new features but
> also some bugs. If you think you have found a bug in LyX 2.3.0beta1, either
> email the LyX developers' mailing list (lyx-devel at lists.lyx.org),
> or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome.
> Please specify if the behavior you are reporting is different from behavior
> in a previous LyX version.
>
> If you have trouble using LyX or have a question, consult the
> documentation that comes with LyX (under Help) and the LyX wiki, which you
> will find at https://wiki.lyx.org/. You can also send email to the LyX
> users'
> list (lyx-users at lists.lyx.org).
>
> The LyX team.
> https://www.lyx.org
>
>

Re: 2.3.0alpha1 tar balls are available

[Liviu Andronic]

On Thu, Apr 27, 2017 at 1:59 AM, Scott Kostyshak  wrote:

> > > Should I create a branch from alpha1-1 and cherry pick only Kornel's
> > > fixes?
> >
> > Yes, that is what I would do: Call it 2.3-alpha1-1 or something like
> that.
>
> I did the following git commands. I called the branch 2.3-alpha1-x
> and I will call the tag 2.3-alpha1-1:
>

It took me some time but I've now prepared the packages for the `alpha1-1`
tarballs. We now have `-dbg` packages as well, and as always the
installation is independent of the main `lyx` installation.

Install the `lyx2.3pre` package for your distribution:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

There were important changes to the recipe, though, so as far as I go the
packages are themselves alpha-ish. Please report if you encounter any
issues.

Regards,
Liviu

Re: [PATCH] weird warnings from coverity

[Liviu Andronic]

On Sat, Apr 8, 2017 at 8:25 PM, Jean-Marc Lasgouttes 
wrote:

> Le 08/04/2017 à 19:38, Richard Heck a écrit :
>
>> I saw that. It looks like a good solution, and it makes the code no less
>> readable.
>>
>
> It took me a lot of time to think about this. At some time my plan was to
> use try/catch, but I do not like adding such a construct in a situation
> where I know that it cannot trigger just for the sake of coverity.
>
>


> I still think this is a bug/shortcoming of coverity. I should not have to
> do that.
>
> In such cases maybe we should just flag it as a false positive then.

Liviu



> JMarc
>
>

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 5:06 PM, Enrico Forestieri  wrote:

> On Tue, Feb 28, 2017 at 03:29:37PM +0100, Liviu Andronic wrote:
> > This doesn't look right, as user:
> >
> > geek@liv-inspiron:~/Build/Devel/lyx$ which moc
> > /home/geek/anaconda3/bin/moc
> > geek@liv-inspiron:~/Build/Devel/lyx$ moc -v
> > moc 5.6.0
> >
> > If I'm not wrong, 'anaconda3' has something to do with the Python
> install.
> > And I most definitely don't have Qt 5.6.0 installed via Synaptic.
> >
> > As root however I get something else:
> > root@liv-inspiron:/tmp# which moc
> > /usr/bin/moc
> > root@liv-inspiron:/tmp# moc -v
> > moc 5.2.1
> >
> > Is it possible that the recent Python packages I had installed have
> somehow
> > screwed my Qt setup?
>
> No, the problem you experiment is that you are using different PATH
> settings when you configure and later when you issue make. The
> configuration process looks for qtchooser and for a moc binary in the
> PATH, and only tries this moc binary if it is in the same directory as
> qtchooser. Otherwise either moc-qt4 or moc-qt5 are tried.
> Unfortunately, due to limitations of the AC_CHECK_PROGS macro, the
> the binaries are to be checked without their path, which is dropped.
> This means that, when you configure, the ~/anaconda3/bin is not in the
> PATH, so that the correct moc is spotted. But later, when you issue
> "make", the ~/anaconda3/bin is in the PATH and the wrong moc is used.
> You have to make sure that the PATH setting you use is the same for
> both configure and make.
>
>
Nicely spotted. I run ./configure from emelFM2, and make from bash (as it's
easier to kill the process if needed). Now the Anaconda install put this in
~/.bashrc:
geek@liv-inspiron:~/Build/Devel/lyx$ cat ~/.bashrc | grep -i anaconda

# added by Anaconda3 4.2.0 installer
export PATH="/home/geek/anaconda3/bin:$PATH"

Which explains the discrepancies. Sorry all for the noise. Now the
compilation advances much more nicely (though I still have `make distclean`
issues, and I'll start a new thread if this issue persists).

Thanks all,
Liviu



> --
> Enrico
>

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 4:11 PM, Kornel Benko  wrote:

> Am Dienstag, 28. Februar 2017 um 15:29:37, schrieb Liviu Andronic <
> landr...@lyx.org>
> > On Tue, Feb 28, 2017 at 3:20 PM, Kornel Benko  wrote:
> >
>
> ...
>
> > >
> > > Maybe the PATH env is not OK, or you have an alias for moc?
> > > # which moc
> > > /usr/bin/moc
> > > # moc -v
> > > Qt Meta Object Compiler version 63 (Qt 4.8.6)
> > >
> > >
> > This doesn't look right, as user:
> >
> > geek@liv-inspiron:~/Build/Devel/lyx$ which moc
> > /home/geek/anaconda3/bin/moc
> > geek@liv-inspiron:~/Build/Devel/lyx$ moc -v
> > moc 5.6.0
> >
> > If I'm not wrong, 'anaconda3' has something to do with the Python
> install.
> > And I most definitely don't have Qt 5.6.0 installed via Synaptic.
> >
> > As root however I get something else:
> > root@liv-inspiron:/tmp# which moc
> > /usr/bin/moc
> > root@liv-inspiron:/tmp# moc -v
> > moc 5.2.1
> >
> > Is it possible that the recent Python packages I had installed have
> somehow
> > screwed my Qt setup?
>
> Remove /home/geek/anaconda3/bin from your PATH while configuring and
> compiling for QT4.
> Apparently root has PATH set without anaconda3.
>
>
Yes, I've just noticed this as well.

geek@liv-inspiron:~/Build/Devel/lyx$ env | grep -i anacon
PATH=/home/geek/anaconda3/bin:/home/geek/Build/Testing/
coverity/cov-analysis-linux64-7.6.0/bin:/usr/local/sbin:/
usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
It seems this was set when I installed Anaconda (for whatever reason). I'll
remove this and try again.

Liviu



> > Thanks,
> > Liviu
> >
> >
> >
> Kornel

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 3:48 PM, Liviu Andronic  wrote:

>
>
> On Tue, Feb 28, 2017 at 3:29 PM, Kornel Benko  wrote:
>
>> Am Dienstag, 28. Februar 2017 um 15:08:33, schrieb Liviu Andronic <
>> landr...@lyx.org>
>> > On Tue, Feb 28, 2017 at 2:58 PM, Jean-Marc Lasgouttes <
>> lasgout...@lyx.org>
>>
>
> > >
>> > geek@liv-inspiron:~/Build/Devel/lyx$ moc -v
>> > moc 5.6.0
>>
>>  That's it.
>>
>> I have also both installed, but can switch in between with
>> setting the environment QT_SELECT
>> # setenv QT_SELECT qt5
>> # moc -v
>> moc 5.2.1
>>
>>
> For some reason this doesn't seem to have an effect here:
>
> geek@liv-inspiron:~/Build/Devel/lyx$ export QT_SELECT=qt4
> geek@liv-inspiron:~/Build/Devel/lyx$ env | grep -i qt_sel
> QT_SELECT=qt4
> geek@liv-inspiron:~/Build/Devel/lyx$ moc -v
> moc 5.6.0
>
>
So this won't work for user, it will work for root:

root@liv-inspiron:/tmp# export QT_SELECT=qt4
root@liv-inspiron:/tmp# env | grep -i qt_sel
QT_SELECT=qt4
root@liv-inspiron:/tmp# moc -v
Qt Meta Object Compiler version 63 (Qt 4.8.6)
root@liv-inspiron:/tmp# export QT_SELECT=qt5
root@liv-inspiron:/tmp# moc -v
moc 5.2.1

I'm stumped.

Liviu



> Liviu
>
>
>> Kornel
>
>
>

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 3:29 PM, Kornel Benko  wrote:

> Am Dienstag, 28. Februar 2017 um 15:08:33, schrieb Liviu Andronic <
> landr...@lyx.org>
> > On Tue, Feb 28, 2017 at 2:58 PM, Jean-Marc Lasgouttes <
> lasgout...@lyx.org>
>

> >
> > geek@liv-inspiron:~/Build/Devel/lyx$ moc -v
> > moc 5.6.0
>
>  That's it.
>
> I have also both installed, but can switch in between with
> setting the environment QT_SELECT
> # setenv QT_SELECT qt5
> # moc -v
> moc 5.2.1
>
>
For some reason this doesn't seem to have an effect here:

geek@liv-inspiron:~/Build/Devel/lyx$ export QT_SELECT=qt4
geek@liv-inspiron:~/Build/Devel/lyx$ env | grep -i qt_sel
QT_SELECT=qt4
geek@liv-inspiron:~/Build/Devel/lyx$ moc -v
moc 5.6.0

Liviu


> Kornel

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 3:29 PM, Kornel Benko  wrote:

> Am Dienstag, 28. Februar 2017 um 15:08:33, schrieb Liviu Andronic <
> landr...@lyx.org>
> > On Tue, Feb 28, 2017 at 2:58 PM, Jean-Marc Lasgouttes <
> lasgout...@lyx.org>
> > wrote:
> >
> > > Le 28/02/2017 à 14:45, Liviu Andronic a écrit :
> > >
> > >> Not sure how to proceed next.
> > >>
> > >
> > > A few questions:
> > >
> > > - do you have only one moc binary?
> > >
> >
> > geek@liv-inspiron:~/Build/Devel/lyx$ ls -l /usr/bin/moc*
> > lrwxrwxrwx 1 root root 9 Feb 19 2014 /usr/bin/moc -> qtchooser
> > lrwxrwxrwx 1 root root 35 May 27 2015 /usr/bin/moc-qt4 ->
> > ../lib/x86_64-linux-gnu/qt4/bin/moc
> >
> >
> > > - do you have qt4 and qt5 in parallel ?
> > >
> >
> > Yes. Qt 4.8.6 and 5.2.1.
> >
> >
> >
> > > - what are the options that moc accepts?
> > >
> > >
> > geek@liv-inspiron:~/Build/Devel/lyx$ moc -v
> > moc 5.6.0
>
>  That's it.
>
> I have also both installed, but can switch in between with
> setting the environment QT_SELECT
> # setenv QT_SELECT qt5
> # moc -v
> moc 5.2.1
>
>
Hmm, I don't have `setenv` here. Which package did you install to get it?


Liviu



> Kornel

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 3:20 PM, Kornel Benko  wrote:

> Am Dienstag, 28. Februar 2017 um 14:45:06, schrieb Liviu Andronic <
> landr...@lyx.org>
> > On Tue, Feb 28, 2017 at 1:39 PM, Kornel Benko  wrote:
> >
> > > Am Dienstag, 28. Februar 2017 um 13:31:42, schrieb Liviu Andronic <
> > > landr...@lyx.org>
>
> ...
>
> > Still no luck.
> >
> > geek@liv-inspiron:~/Build/Devel/lyx$ export QT_SELECT=qt4
> > geek@liv-inspiron:~/Build/Devel/lyx$ env | grep -i qt_se
> > QT_SELECT=qt4
> > geek@liv-inspiron:~/Build/Devel/lyx$ make
> > [...]
> > Making all in src
> > make[2]: Entering directory `/home/geek/Build/Devel/lyx/src'
> > rm -f hash-temp \
> > @echo " GEN lyx_commit_hash.h";hash=`cd ".." && git log -1
> > --pretty=format:%H 2>/dev/null || echo none` ; \
> > sed s/@LYX_GIT_COMMIT_HASH@/$hash/ "."/lyx_commit_hash.h.in >hash-temp
> ; \
> > cmp -s lyx_commit_hash.h hash-temp || cp hash-temp lyx_commit_hash.h ; \
> > rm -f hash-temp
> > GEN moc_Compare.cpp
> > Unknown options: q, t, =, q, t, 4.
> > make[2]: *** [moc_Compare.cpp] Error 1
> > make[2]: Leaving directory `/home/geek/Build/Devel/lyx/src'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/home/geek/Build/Devel/lyx'
> > make: *** [all] Error 2
>
> I am out of suggestions.
> I retried on clean build tree without any error.
> # cd 
> # /configure --bindir=/usr/local/bin
> --datarootdir=/usr/local/share/lyx2.3 --with-version-suffix=2.3
> # make
>
> Maybe the PATH env is not OK, or you have an alias for moc?
> # which moc
> /usr/bin/moc
> # moc -v
> Qt Meta Object Compiler version 63 (Qt 4.8.6)
>
>
This doesn't look right, as user:

geek@liv-inspiron:~/Build/Devel/lyx$ which moc
/home/geek/anaconda3/bin/moc
geek@liv-inspiron:~/Build/Devel/lyx$ moc -v
moc 5.6.0

If I'm not wrong, 'anaconda3' has something to do with the Python install.
And I most definitely don't have Qt 5.6.0 installed via Synaptic.

As root however I get something else:
root@liv-inspiron:/tmp# which moc
/usr/bin/moc
root@liv-inspiron:/tmp# moc -v
moc 5.2.1

Is it possible that the recent Python packages I had installed have somehow
screwed my Qt setup?

Thanks,
Liviu



> Kornel

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 12:16 PM, Liviu Andronic  wrote:

> I have troubles compiling current GIT. Today I've updated from e7654d9 ->
> a1faa41, and all of a sudden master no longer compiles. Before the
> compilation failures I did a `make distclean` which worked fine.  I'm using
> libqt4-dev 4.8.5 on Ubuntu 14.04.
>

Also, I've done a git bisect, and I couldn't find any commit that I could
compile, i.e. I can't even compile e7654d9. Which points to something being
wrong on my system.

Liviu

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 2:58 PM, Jean-Marc Lasgouttes 
wrote:

> Le 28/02/2017 à 14:45, Liviu Andronic a écrit :
>
>> Not sure how to proceed next.
>>
>
> A few questions:
>
> - do you have only one moc binary?
>

geek@liv-inspiron:~/Build/Devel/lyx$ ls -l /usr/bin/moc*
lrwxrwxrwx 1 root root 9 Feb 19 2014 /usr/bin/moc -> qtchooser
lrwxrwxrwx 1 root root 35 May 27 2015 /usr/bin/moc-qt4 ->
../lib/x86_64-linux-gnu/qt4/bin/moc


> - do you have qt4 and qt5 in parallel ?
>

Yes. Qt 4.8.6 and 5.2.1.



> - what are the options that moc accepts?
>
>
geek@liv-inspiron:~/Build/Devel/lyx$ moc -v
moc 5.6.0
geek@liv-inspiron:~/Build/Devel/lyx$ moc --help
Usage: moc [options] [header-file] [@option-file]
Qt Meta Object Compiler version 67 (Qt 5.6.0)

Options:
-h, --help Displays this help.
-v, --version Displays version information.
-o  Write output to file rather than stdout.
-I  Add dir to the include path for header files.
-F  Add Mac framework to the include path for header
files.
-E Preprocess only; do not generate meta object code.
-D  Define macro, with optional definition.
-U  Undefine macro.
-M  Add key/value pair to plugin meta data
-i Do not generate an #include statement.
-p  Path prefix for included file.
-f  Force #include  (overwrite default).
-b  Prepend #include  (preserve default include).
-n  Do not display notes (-nn) or warnings (-nw).
Compatibility option.
--no-notes Do not display notes.
--no-warnings Do not display warnings (implies --no-notes).
--ignore-option-clashes Ignore all options that conflict with compilers,
like -pthread conflicting with moc's -p option.

Arguments:
[header-file] Header file to read from, otherwise stdin.
[@option-file] Read additional options from option-file.


geek@liv-inspiron:~/Build/Devel/lyx$ moc-qt4 -v
Qt Meta Object Compiler version 63 (Qt 4.8.6)
geek@liv-inspiron:~/Build/Devel/lyx$ moc-qt4 --help
moc: Invalid argument
Usage: moc [options] 
-o write output to file rather than stdout
-I add dir to the include path for header files
-E preprocess only; do not generate meta object code
-D[=] define macro, with optional definition
-U undefine macro
-i do not generate an #include statement
-p path prefix for included file
-f[] force #include, optional file name
-nn do not display notes
-nw do not display warnings
@ read additional options from file
-v display version of moc


Liviu



> JMarc
>
>

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 1:39 PM, Kornel Benko  wrote:

> Am Dienstag, 28. Februar 2017 um 13:31:42, schrieb Liviu Andronic <
> landr...@lyx.org>
> > On Tue, Feb 28, 2017 at 1:07 PM, Kornel Benko  wrote:
> >
> > > Am Dienstag, 28. Februar 2017 um 12:50:05, schrieb Liviu Andronic <
> > > landr...@lyx.org>
> > > > On Tue, Feb 28, 2017 at 12:30 PM, Jean-Marc Lasgouttes <
> > > lasgout...@lyx.org>
> > > > wrote:
> > > >
> > > > > Le 28/02/2017 à 12:16, Liviu Andronic a écrit :
> > > > >
> > > > >> Dear all,
> > > > >> I have troubles compiling current GIT. Today I've updated from
> e7654d9
> > > > >> -> a1faa41, and all of a sudden master no longer compiles. Before
> the
> > > > >> compilation failures I did a `make distclean` which worked fine.
> I'm
> > > > >> using libqt4-dev 4.8.5 on Ubuntu 14.04.
>
> ...
>
> > And I'm still getting the same compilation failure:
> > Making all in src
> > make[2]: Entering directory `/home/geek/Build/Devel/lyx/src'
> > rm -f hash-temp \
> > @echo " GEN lyx_commit_hash.h";hash=`cd ".." && git log -1
> > --pretty=format:%H 2>/dev/null || echo none` ; \
> > sed s/@LYX_GIT_COMMIT_HASH@/$hash/ "."/lyx_commit_hash.h.in >hash-temp
> ; \
> > cmp -s lyx_commit_hash.h hash-temp || cp hash-temp lyx_commit_hash.h ; \
> > rm -f hash-temp
> > GEN moc_Compare.cpp
> > Unknown options: q, t, =, q, t, 4.
> > make[2]: *** [moc_Compare.cpp] Error 1
> > make[2]: Leaving directory `/home/geek/Build/Devel/lyx/src'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/home/geek/Build/Devel/lyx'
> > make: *** [all] Error 2
> >
>
> I am using also 'export QT_SELECT=qt4" before compiling.
>
>

Still no luck.

geek@liv-inspiron:~/Build/Devel/lyx$ export QT_SELECT=qt4
geek@liv-inspiron:~/Build/Devel/lyx$ env | grep -i qt_se
QT_SELECT=qt4
geek@liv-inspiron:~/Build/Devel/lyx$ make
[...]
Making all in src
make[2]: Entering directory `/home/geek/Build/Devel/lyx/src'
rm -f hash-temp \
@echo " GEN lyx_commit_hash.h";hash=`cd ".." && git log -1
--pretty=format:%H 2>/dev/null || echo none` ; \
sed s/@LYX_GIT_COMMIT_HASH@/$hash/ "."/lyx_commit_hash.h.in >hash-temp ; \
cmp -s lyx_commit_hash.h hash-temp || cp hash-temp lyx_commit_hash.h ; \
rm -f hash-temp
GEN moc_Compare.cpp
Unknown options: q, t, =, q, t, 4.
make[2]: *** [moc_Compare.cpp] Error 1
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/geek/Build/Devel/lyx'
make: *** [all] Error 2






> > And if I'm using JMarc's suggestion, I'm still getting the same error as
> > before:
>

I also tried supplying `moc-qt4` and the compilation gets farther, but
still fails:

geek@liv-inspiron:~/Build/Devel/lyx$ make QT_MOC=moc-qt4
[...]
Making all in frontends
make[4]: Entering directory `/home/geek/Build/Devel/lyx/src/frontends'
Making all in qt4
make[5]: Entering directory `/home/geek/Build/Devel/lyx/src/frontends/qt4'
GEN ui_AboutUi.h
Unknown option 'qt'.
make[5]: *** [ui_AboutUi.h] Error 1
make[5]: Leaving directory `/home/geek/Build/Devel/lyx/src/frontends/qt4'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/geek/Build/Devel/lyx/src/frontends'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/geek/Build/Devel/lyx'
make: *** [all] Error 2


Not sure how to proceed next.

Liviu



>
> ...
>
> > > Yes, but I think that it is only because of previous compilation with
> qt5.
> > >
> > >
> > I can't be sure, but I don't think I ever compiled with Qt5 in this tree.
> > What's more, before updating GIT I did a full `make distclean` which
> > completed successfully, so the tree should be clean as far as past
> > compilations are concerned.
> >
> > Liviu
> >
>
> Kornel

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 1:07 PM, Kornel Benko  wrote:

> Am Dienstag, 28. Februar 2017 um 12:50:05, schrieb Liviu Andronic <
> landr...@lyx.org>
> > On Tue, Feb 28, 2017 at 12:30 PM, Jean-Marc Lasgouttes <
> lasgout...@lyx.org>
> > wrote:
> >
> > > Le 28/02/2017 à 12:16, Liviu Andronic a écrit :
> > >
> > >> Dear all,
> > >> I have troubles compiling current GIT. Today I've updated from e7654d9
> > >> -> a1faa41, and all of a sudden master no longer compiles. Before the
> > >> compilation failures I did a `make distclean` which worked fine.  I'm
> > >> using libqt4-dev 4.8.5 on Ubuntu 14.04.
> > >>
> > >
> > > Dear Liviu,
> > >
> > > What can you tell us about your 'moc' binary? What version of Qt is it
> > > from?
> > > It seems that it does not understand the '-qt=qt4' argument.
> > >
> > >
> > I'm using libqt4-dev 4.8.5 on Ubuntu 14.04. Previously compilations
> worked
> > fine, and I hadn't changed Qt version since.
> >
>
> So do I.
>
> >
> > > Do you have qtchooser installed? What does 'qtchooser -l' return?
> > >
> > >
> > geek@liv-inspiron:~/Build/Devel/lyx$ qtchooser -l
> > 4
> > 5
> > default
> > qt4-i386-linux-gnu
> > qt4-x86_64-linux-gnu
> > qt4
> > qt5-x86_64-linux-gnu
> > qt5
> >
> >
> > > Note that on my ancient ubuntu 12.04, I have
> > > QT_MOC=moc-qt4
> > >
> > > As a workaround for now, you can probably configure with QT_MOC=moc,
> or at
> > > least pass this to make.
> > >
> > >
> > Still getting an error, but a later one:
> > geek@liv-inspiron:~/Build/Devel/lyx$ make QT_MOC=moc
> > [...]
> > GEN moc_Compare.cpp
> > GEN moc_PreviewLoader.cpp
> > make all-recursive
> > make[3]: Entering directory `/home/geek/Build/Devel/lyx/src'
> > Making all in support
> > make[4]: Entering directory `/home/geek/Build/Devel/lyx/src/support'
> > moc -o moc_ConsoleApplicationPrivate.cpp ConsoleApplicationPrivate.h
> > moc -o moc_SystemcallPrivate.cpp SystemcallPrivate.h
> > make all-am
> > make[5]: Entering directory `/home/geek/Build/Devel/lyx/src/support'
> > CXX FileMonitor.o
> > CXX ConsoleApplication.o
> > In file included from ConsoleApplication.cpp:51:0:
> > moc_ConsoleApplicationPrivate.cpp:15:2: error: #error "This file was
> > generated using the moc from 5.6.0. It"
> > #error "This file was generated using the moc from 5.6.0. It"
> >
>
> Which apparently means that 'make distclean' is not working.
> Remove all moc_*.cpp ui_*.h
>
>
I removed two moc_*.cpp files (and there were no ui_*.h). Then:
make clean
./autogen.sh
./configure

And I'm still getting the same compilation failure:
Making all in src
make[2]: Entering directory `/home/geek/Build/Devel/lyx/src'
rm -f hash-temp \
@echo " GEN lyx_commit_hash.h";hash=`cd ".." && git log -1
--pretty=format:%H 2>/dev/null || echo none` ; \
sed s/@LYX_GIT_COMMIT_HASH@/$hash/ "."/lyx_commit_hash.h.in >hash-temp ; \
cmp -s lyx_commit_hash.h hash-temp || cp hash-temp lyx_commit_hash.h ; \
rm -f hash-temp
GEN moc_Compare.cpp
Unknown options: q, t, =, q, t, 4.
make[2]: *** [moc_Compare.cpp] Error 1
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/geek/Build/Devel/lyx'
make: *** [all] Error 2


And if I'm using JMarc's suggestion, I'm still getting the same error as
before:
geek@liv-inspiron:~/Build/Devel/lyx$ make QT_MOC=moc
[...]
GEN moc_Compare.cpp
GEN moc_PreviewLoader.cpp
make all-recursive
make[3]: Entering directory `/home/geek/Build/Devel/lyx/src'
Making all in support
make[4]: Entering directory `/home/geek/Build/Devel/lyx/src/support'
moc -o moc_ConsoleApplicationPrivate.cpp ConsoleApplicationPrivate.h
moc -o moc_SystemcallPrivate.cpp SystemcallPrivate.h
make all-am
make[5]: Entering directory `/home/geek/Build/Devel/lyx/src/support'
CXX FileMonitor.o
CXX ConsoleApplication.o
In file included from ConsoleApplication.cpp:51:0:
moc_ConsoleApplicationPrivate.cpp:15:2: error: #error "This file was
generated using the moc from 5.6.0. It"
#error "This file was generated using the moc from 5.6.0. It"
^
moc_ConsoleApplicationPrivate.cpp:16:2: error: #error "cannot be used with
the include files from this version of Qt."
#error "cannot be used with the include files from this version of Qt."
^
moc_ConsoleApplicationPrivate

Re: master GIT broken?

[Liviu Andronic]

On Tue, Feb 28, 2017 at 12:30 PM, Jean-Marc Lasgouttes 
wrote:

> Le 28/02/2017 à 12:16, Liviu Andronic a écrit :
>
>> Dear all,
>> I have troubles compiling current GIT. Today I've updated from e7654d9
>> -> a1faa41, and all of a sudden master no longer compiles. Before the
>> compilation failures I did a `make distclean` which worked fine.  I'm
>> using libqt4-dev 4.8.5 on Ubuntu 14.04.
>>
>
> Dear Liviu,
>
> What can you tell us about your 'moc' binary? What version of Qt is it
> from?
> It seems that it does not understand the '-qt=qt4' argument.
>
>
I'm using libqt4-dev 4.8.5 on Ubuntu 14.04. Previously compilations worked
fine, and I hadn't changed Qt version since.



> Do you have qtchooser installed? What does 'qtchooser -l' return?
>
>
geek@liv-inspiron:~/Build/Devel/lyx$ qtchooser -l
4
5
default
qt4-i386-linux-gnu
qt4-x86_64-linux-gnu
qt4
qt5-x86_64-linux-gnu
qt5


> Note that on my ancient ubuntu 12.04, I have
> QT_MOC=moc-qt4
>
> As a workaround for now, you can probably configure with QT_MOC=moc, or at
> least pass this to make.
>
>
Still getting an error, but a later one:
geek@liv-inspiron:~/Build/Devel/lyx$ make QT_MOC=moc
[...]
GEN moc_Compare.cpp
GEN moc_PreviewLoader.cpp
make all-recursive
make[3]: Entering directory `/home/geek/Build/Devel/lyx/src'
Making all in support
make[4]: Entering directory `/home/geek/Build/Devel/lyx/src/support'
moc -o moc_ConsoleApplicationPrivate.cpp ConsoleApplicationPrivate.h
moc -o moc_SystemcallPrivate.cpp SystemcallPrivate.h
make all-am
make[5]: Entering directory `/home/geek/Build/Devel/lyx/src/support'
CXX FileMonitor.o
CXX ConsoleApplication.o
In file included from ConsoleApplication.cpp:51:0:
moc_ConsoleApplicationPrivate.cpp:15:2: error: #error "This file was
generated using the moc from 5.6.0. It"
#error "This file was generated using the moc from 5.6.0. It"
^
moc_ConsoleApplicationPrivate.cpp:16:2: error: #error "cannot be used with
the include files from this version of Qt."
#error "cannot be used with the include files from this version of Qt."
^
moc_ConsoleApplicationPrivate.cpp:17:2: error: #error "(The moc has changed
too much.)"
#error "(The moc has changed too much.)"
^
moc_ConsoleApplicationPrivate.cpp:22:5: error: ‘QByteArrayData’ does not
name a type
QByteArrayData data[3];
^
moc_ConsoleApplicationPrivate.cpp:28:24: error: ‘QByteArrayData’ was not
declared in this scope
- idx * sizeof(QByteArrayData)) \
^
moc_ConsoleApplicationPrivate.cpp:32:1: note: in expansion of macro
‘QT_MOC_LITERAL’
QT_MOC_LITERAL(0, 0, 39), // "lyx::support::ConsoleApplicat..."
^
moc_ConsoleApplicationPrivate.cpp:29:5: error:
‘Q_STATIC_BYTE_ARRAY_DATA_HEADER_INITIALIZER_WITH_OFFSET’ was not declared
in this scope
)
^
moc_ConsoleApplicationPrivate.cpp:32:1: note: in expansion of macro
‘QT_MOC_LITERAL’
QT_MOC_LITERAL(0, 0, 39), // "lyx::support::ConsoleApplicat..."
^
moc_ConsoleApplicationPrivate.cpp:28:24: error: ‘QByteArrayData’ was not
declared in this scope
- idx * sizeof(QByteArrayData)) \
^
moc_ConsoleApplicationPrivate.cpp:33:1: note: in expansion of macro
‘QT_MOC_LITERAL’
QT_MOC_LITERAL(1, 40, 6), // "doExec"
^
moc_ConsoleApplicationPrivate.cpp:29:5: error:
‘Q_STATIC_BYTE_ARRAY_DATA_HEADER_INITIALIZER_WITH_OFFSET’ was not declared
in this scope
)
^
moc_ConsoleApplicationPrivate.cpp:33:1: note: in expansion of macro
‘QT_MOC_LITERAL’
QT_MOC_LITERAL(1, 40, 6), // "doExec"
^
moc_ConsoleApplicationPrivate.cpp:28:24: error: ‘QByteArrayData’ was not
declared in this scope
- idx * sizeof(QByteArrayData)) \
^
moc_ConsoleApplicationPrivate.cpp:34:1: note: in expansion of macro
‘QT_MOC_LITERAL’
QT_MOC_LITERAL(2, 47, 0) // ""
^
moc_ConsoleApplicationPrivate.cpp:29:5: error:
‘Q_STATIC_BYTE_ARRAY_DATA_HEADER_INITIALIZER_WITH_OFFSET’ was not declared
in this scope
)
^
moc_ConsoleApplicationPrivate.cpp:34:1: note: in expansion of macro
‘QT_MOC_LITERAL’
QT_MOC_LITERAL(2, 47, 0) // ""
^
In file included from ConsoleApplication.cpp:51:0:
moc_ConsoleApplicationPrivate.cpp:78:103: error: ‘const struct
qt_meta_stringdata_lyx__support__ConsoleApplicationPrivate_t’ has no member
named ‘data’
{ &QCoreApplication::staticMetaObject,
qt_meta_stringdata_lyx__support__ConsoleApplicationPrivate.data,
^
moc_ConsoleApplicationPrivate.cpp:79:82: error: ‘Q_NULLPTR’ was not
declared in this scope
qt_meta_data_lyx__support__ConsoleApplicationPrivate, qt_static_metacall,
Q_NULLPTR, Q_NULLPTR}
^
moc_ConsoleApplicationPrivate.cpp:79:93: error: ‘Q_NULLPTR’ was not
declared in this scope
qt_meta_data_lyx__support__ConsoleApplicationPrivate, qt_static_metacall,
Q_NULLPTR, Q_NULLPTR}
^
moc_ConsoleApplicationPrivate.cpp: In member function ‘virtual const
QMetaObject* lyx::support::ConsoleApplicationPrivate::metaObje

master GIT broken?

[Liviu Andronic]

Dear all,
I have troubles compiling current GIT. Today I've updated from e7654d9 ->
a1faa41, and all of a sudden master no longer compiles. Before the
compilation failures I did a `make distclean` which worked fine.  I'm using
libqt4-dev 4.8.5 on Ubuntu 14.04.

Here's what I see:
>"/home/geek/Build/Devel/lyx/autogen.sh" (29715)
Using automake (GNU automake) 1.14.1
Using autoconf (GNU Autoconf) 2.69
Building macros...
Building config header template...
Building Makefile templates...
Building configure...
Building po/POTFILES.in...

run "./configure && make"

>"/home/geek/Build/Devel/lyx/autogen.sh" (29715) returned '0'

>/home/geek/Build/Devel/lyx/configure (30084)
configuring LyX version 2.3.0dev
[...]

Configuration
Host type: x86_64-unknown-linux-gnu
Special build flags: build=development warnings assertions stdlib-debug
use-aspell use-enchant use-hunspell
C++ Compiler: g++ (4.8)
C++ Compiler flags: -Wall -Wextra -g -O -std=c++11
C++ Compiler user flags:
Linker flags:
Linker user flags:
Qt Frontend:
Qt version: 4.8.6
Packaging: posix
LyX binary dir: /usr/local/bin
LyX files dir: /usr/local/share/lyx

Configuration of LyX was successful.
Type 'make' to compile the program,
and then 'make install' to install it.
>/home/geek/Build/Devel/lyx/configure (30084) returned '0'

geek@liv-inspiron:~/Build/Devel/lyx$ make
make all-recursive
make[1]: Entering directory `/home/geek/Build/Devel/lyx'
Making all in autotests
make[2]: Entering directory `/home/geek/Build/Devel/lyx/autotests'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/autotests'
Making all in config
make[2]: Entering directory `/home/geek/Build/Devel/lyx/config'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/config'
Making all in development
make[2]: Entering directory `/home/geek/Build/Devel/lyx/development'
make[3]: Entering directory `/home/geek/Build/Devel/lyx/development'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/geek/Build/Devel/lyx/development'
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/development'
Making all in po
make[2]: Entering directory `/home/geek/Build/Devel/lyx/po'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/po'
Making all in 3rdparty
make[2]: Entering directory `/home/geek/Build/Devel/lyx/3rdparty'
Making all in boost
make[3]: Entering directory `/home/geek/Build/Devel/lyx/3rdparty/boost'
CXX libs/regex/src/c_regex_traits.o
CXX libs/regex/src/cpp_regex_traits.o
CXX libs/regex/src/cregex.o
CXX libs/regex/src/fileiter.o
CXX libs/regex/src/instances.o
CXX libs/regex/src/posix_api.o
CXX libs/regex/src/regex.o
CXX libs/regex/src/regex_debug.o
CXX libs/regex/src/regex_raw_buffer.o
CXX libs/regex/src/regex_traits_defaults.o
CXX libs/regex/src/w32_regex_traits.o
CXX libs/regex/src/wc_regex_traits.o
CXX libs/regex/src/wide_posix_api.o
CXX libs/regex/src/winstances.o
CXX libs/regex/src/static_mutex.o
AR liblyxboost.a
make[3]: Leaving directory `/home/geek/Build/Devel/lyx/3rdparty/boost'
make[3]: Entering directory `/home/geek/Build/Devel/lyx/3rdparty'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/geek/Build/Devel/lyx/3rdparty'
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/3rdparty'
Making all in src
make[2]: Entering directory `/home/geek/Build/Devel/lyx/src'
rm -f hash-temp \
@echo " GEN lyx_commit_hash.h";hash=`cd ".." && git log -1
--pretty=format:%H 2>/dev/null || echo none` ; \
sed s/@LYX_GIT_COMMIT_HASH@/$hash/ "."/lyx_commit_hash.h.in >hash-temp ; \
cmp -s lyx_commit_hash.h hash-temp || cp hash-temp lyx_commit_hash.h ; \
rm -f hash-temp
GEN moc_Compare.cpp
Unknown options: q, t, =, q, t, 4.
make[2]: *** [moc_Compare.cpp] Error 1
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/geek/Build/Devel/lyx'
make: *** [all] Error 2


In src/Makefile I have:
QT_MOC = moc -qt=qt4

And config.log is attached.

In addition, now `make distclean` fails as well:
>make distclean (9653)
[...]
Making distclean in .
make[2]: Entering directory `/home/geek/Build/Devel/lyx/src'
Makefile:2443:
support/tests/.deps/check_ExternalTransforms-dummy_functions.Po: No such
file or directory
Makefile:2444: support/tests/.deps/check_Length-dummy_functions.Po: No such
file or directory
Makefile:2445:
support/tests/.deps/check_ListingsCaption-dummy_functions.Po: No such file
or directory
Makefile:2446: support/tests/.deps/check_layout-dummy_functions.Po: No such
file or directory
make[2]: *** No rule to make target
`support/tests/.deps/check_layout-dummy_functions.Po'. Stop.
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[1]: *** [distclean-recursive] Error 1
make[1]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make: *** [distclean-recursive] Error 1
>make distclean (9653) returned '2'

So right now I'm unable to completely clean-up the tree.

Re: middle-click to open child documents?

[Liviu Andronic]

On Sat, Aug 6, 2016 at 4:56 AM, Scott Kostyshak  wrote:
> Dear LyX devs,
>
> The following behavior is shared by Firefox and Chromium:
>
> ctrl+left-click opens a tab but does not switch to it
> middle-click is the same as ctrl+left click
> shift+middle-click opens the tab and switches to it
>
> Since learning about middle-click to open tabs in browsers, I find it
> surprisingly convenient. I can lazily use one hand on the mouse for
> navigating and setting up tabs how I want them.
>


> Currently in LyX, to open an included file I think the only way is to
> right-click and go to "Edit Included file". Would we want to allow the
> behavior described above for browsers for opening child documents in
> LyX?
>
I would find this useful and intuitive. I too find opening included
files via right-click like a cumbersome arrangement, and such a power
feature (middle-click) would only be used by those in the know. For
those who don't know it and do it by mistake, the consequences are
minor: the user can easily close the opened document.

Regards,
Liviu


> The current behavior when middle-clicking on a child document is
> the same as middle-clicking in text: paste selection (assuming
> middle-button pasting is not disabled in preferences) to the left of the
> inset.
>
> Scott

Re: Ubuntu PPA: need to remove the default repo package first?

[Liviu Andronic]

On Sun, Jul 31, 2016 at 5:57 AM, Scott Kostyshak  wrote:
> An edit was made to the LyXOnUbuntu page:
>
> http://wiki.lyx.org/LyX/LyXOnUbuntu?action=diff#diff1469928065
>
> The user "JH" had a problem when using the Ubuntu PPA and changed the
> wiki page to suggest that users remove the default repo lyx package
> before using the PPA. Is this indeed the correct advice? I think that
> should not be necessary, but I've seen a couple of issues regarding
> upgrading LyX versions on Ubuntu, so I'm not sure.
>

It might be, but I'm not sure. Sometimes there are minor
incompatibilities between packages (e.g. 'lyx-common' from default
repos containing icons that the PPA packages contain in 'lyx', though
I speak from memory), in which case it's indeed a good idea to first
remove the Ubuntu lyx packages and then install the PPA ones. Either
way, I don't think this additional step is much of an issue, and if
you don't you'll fix your system quickly enough in any case.

Liviu


> Scott

Re: Combo Box for Custom Insets

[Liviu Andronic]

On Sat, Jun 25, 2016 at 8:05 PM, Richard Heck  wrote:
> On 06/25/2016 12:23 PM, Liviu Andronic wrote:
>> On Sat, Jun 25, 2016 at 6:00 PM, Richard Heck  wrote:
>>> I've fixed both these issues with the attached.
>>>
>> I have trouble applying this patch. I've tried everything from patch
>> -p1 < filename.patch to git apply filename.patch on a clean tree and
>> it fails.
>
> Try this one. I've rebased against current master.
>
Tried the last patch and looks very good. This'll make a lot of module
users very happy campers. :)

The only minor niggle is that when the user selects ""
(the first line), LyX should return focus to the editing area.
Currently the focus stays with the combobox in this case.

Liviu

PS In my opinion the text-based approach in the current patch would be
superior UI-wise to an icons-based approach (whether a toolbar or in a
pop-up a la math). Not least, the patch mirrors faithfully the Insert
> Custom Insets menu, which is what users would probably expect.


> Richard
>

Re: Combo Box for Custom Insets

[Liviu Andronic]

On Sat, Jun 25, 2016 at 11:41 PM, Richard Heck  wrote:
> On 06/25/2016 04:55 PM, Jean-Marc Lasgouttes wrote:
>> Le 25/06/2016 22:37, Guillaume Munch a écrit :
>>> Le 25/06/2016 19:15, Richard Heck a écrit :

 For now, the branch is here:
 http://git.lyx.org/?p=developers/rgheck/lyx.git;a=shortlog;h=refs/heads/features/CustomInsets



>>>
>>> If you are satisfied with it then you could commit it, I think.
>>> What is your plan?
>>
>> Another possibility would be that the Insets toolbar tag inserts a
>> series of icons. One would just have to provide the relevant icons.
>> This is a better UI that a Combox IMO. The difficulty here is not the
>> code, but providing correct icons.
>

> But then it doesn't work with non-LyX-provided insets, i.e., ones you
> make yourself. If you had a lot of such insets, this would get very
> messy, too.
>

I would agree. Also, icons would work when having only a limited
number of custom insets available --- but if using various modules the
list becomes as populated as the Styles, then icons might ultimately
prove more cumbersome. As for the availability of icons, if no icon is
present (i.e. homebrewed module) then presumably the text will be used
alternatively, and currently some custom insets have very verbose
names so screen real estate will be an issue.

Personally I like the idea of making custom insets be UI-wise as
similarly as possible to the Style combobox, since the two perform
conceptually similar functions (at least from the perspective of the
end user).

Liviu


> I'd be happy if it were done as an icon-based menu. As I've said, I just
> don't know how to do that.
>
> Richard
>

Re: Combo Box for Custom Insets

[Liviu Andronic]

On Sat, Jun 25, 2016 at 7:30 PM, Pavel Sanda  wrote:
> Liviu Andronic wrote:
>> The next patch would create the file src/frontends/qt4/InsetCombo.cpp,
>> which already exists! Assume -R? [n]
>> Apply anyway? [n]
>
> Delete new files (InsetCombo*). P

That was it, thanks.

Liviu

Re: Combo Box for Custom Insets

[Liviu Andronic]

On Sat, Jun 25, 2016 at 6:29 PM, Kornel Benko  wrote:
> Am Samstag, 25. Juni 2016 um 18:23:03, schrieb Liviu Andronic 
> 
>> On Sat, Jun 25, 2016 at 6:00 PM, Richard Heck  wrote:
>> > I've fixed both these issues with the attached.
>> >
>> I have trouble applying this patch. I've tried everything from patch
>> -p1 < filename.patch to git apply filename.patch on a clean tree and
>> it fails.
>
> I had no problems with this in master branch. The only difference was
> patching file src/frontends/qt4/GuiView.cpp
> Hunk #9 succeeded at 4236 (offset 5 lines).
> Hunk #10 succeeded at 4374 (offset 5 lines).
>

I also get this, but the patch doesn't seem to apply cleanly:

sh>patch -p1 < "0001-Initial-work-for-inset-toolbar-combo2.patch" (7483)
(Stripping trailing CRs from patch; use --binary to disable.)
patching file lib/ui/stdtoolbars.inc
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/frontends/qt4/GuiToolbar.cpp
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/frontends/qt4/GuiView.cpp
Hunk #9 succeeded at 4236 (offset 5 lines).
Hunk #10 succeeded at 4374 (offset 5 lines).
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/frontends/qt4/GuiView.h
The next patch would create the file src/frontends/qt4/InsetCombo.cpp,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
The next patch would create the file src/frontends/qt4/InsetCombo.h,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/frontends/qt4/Makefile.am
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/frontends/qt4/Toolbars.cpp
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/frontends/qt4/Toolbars.h
sh>patch -p1 < ... 1-Initial-work-for-inset-toolbar-combo2.patch"
(7483) returned '1'


Liviu


>> >git apply "0001-Initial-work-for-inset-toolbar-combo2.patch" (7324)
>> 0001-Initial-work-for-inset-toolbar-combo2.patch:28: trailing whitespace.
>> Separator0001-Initial-work-for-inset-toolbar-combo2.patch:29: trailing
>> whitespace.
>> Insets0001-Initial-work-for-inset-toolbar-combo2.patch:41: trailing 
>> whitespace.
>> #include "InsetCombo.h"0001-Initial-work-for-inset-toolbar-combo2.patch:49:
>> trailing whitespace.
>> case ToolbarItem::INSETS:
>> {0001-Initial-work-for-inset-toolbar-combo2.patch:50: trailing
>> whitespace.
>> InsetCombo * insets = owner_.getInsetCombo();fatal: git apply: bad
>> git-diff - expected /dev/null on line 187
>> >git apply "0001-Initial-work-for-inset-toolbar-combo2.patch" (7324) 
>> >returned '128'
>>
>>
>> Any pointers?
>>
>> Thanks,
>> Liviu
>>
>>
>> > Richard
>
> Kornel

Re: Combo Box for Custom Insets

[Liviu Andronic]

On Sat, Jun 25, 2016 at 6:00 PM, Richard Heck  wrote:
> I've fixed both these issues with the attached.
>
I have trouble applying this patch. I've tried everything from patch
-p1 < filename.patch to git apply filename.patch on a clean tree and
it fails.

>git apply "0001-Initial-work-for-inset-toolbar-combo2.patch" (7324)
0001-Initial-work-for-inset-toolbar-combo2.patch:28: trailing whitespace.
Separator0001-Initial-work-for-inset-toolbar-combo2.patch:29: trailing
whitespace.
Insets0001-Initial-work-for-inset-toolbar-combo2.patch:41: trailing whitespace.
#include "InsetCombo.h"0001-Initial-work-for-inset-toolbar-combo2.patch:49:
trailing whitespace.
case ToolbarItem::INSETS:
{0001-Initial-work-for-inset-toolbar-combo2.patch:50: trailing
whitespace.
InsetCombo * insets = owner_.getInsetCombo();fatal: git apply: bad
git-diff - expected /dev/null on line 187
>git apply "0001-Initial-work-for-inset-toolbar-combo2.patch" (7324) returned 
>'128'


Any pointers?

Thanks,
Liviu


> Richard
>

Re: Combo Box for Custom Insets

[Liviu Andronic]

On Sat, Jun 25, 2016 at 12:23 AM, Richard Heck  wrote:
>
> Attached please find a patch that implements a combo box for custom
> insets, much like the layout box. This is a very simple version. More
> complicated ones might also have an InsetLayout tag that governed
> whether an inset would appear here. It would also be very easy to adapt
> this also to give us a combo for charstyles.
>
Looks good. Couple of comments:
- since unlike styles we don't always have a "default" chunk, probably
the first item in the list should be something like: . This will also make the UI more intuitive.
- using the knitr module, while I can insert Chunks without trouble,
for S/R expression and Sweave Opts I get "undefined" inset


Regards,
Liviu



> Comments welcome.
>
> Richard
>

Re: lyx and dark color schemes

[Liviu Andronic]

On Wed, Jun 15, 2016 at 5:52 PM, Guillaume Munch  wrote:
> Le 15/06/2016 15:47, Liviu Andronic a écrit :
>>
>> On Wed, Jun 15, 2016 at 3:35 PM, Guillaume Munch  wrote:
>>>
>>> Le 14/06/2016 22:14, Cor Blom a écrit :
>>>>
>>>>
>>>> Op 14-06-16 om 22:21 schreef Guillaume Munch:
>>>>>
>>>>>
>>>>> Le 14/06/2016 21:16, Cor Blom a écrit :
>>>>>>
>>>>>>
>>>>>> Op 14-06-16 om 22:09 schreef Guillaume Munch:
>>>>>>>
>>>>>>>
>>>>>>> Le 14/06/2016 18:44, Cor Blom a écrit :
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Recently I tried lyx with a dark color scheme (breeze-dark  under
>>>>>>>> kde
>>>>>>>> plasma 5). Ihe toolbar icons are problematic, but I know how to fix
>>>>>>>> that
>>>>>>>> (and the oxygen set is not that bad against a dark background). In
>>>>>>>> general I'm happy about it. There is one issue. I don't know whether
>>>>>>>> it's possible and I'm missing something, or not.
>>>>>>>>
>>>>>>>> Under de Documents > Settings, in the preamble part, blue is used
>>>>>>>> for
>>>>>>>> code. Against a dark background this is unreadable. Also in the code
>>>>>>>> view panel, de latex commands are blue, which makes them
>>>>>>>> unreadable. Is
>>>>>>>> that color configurable somewhere? I've searched but can't find the
>>>>>>>> solution.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Cor
>>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Can you compile master and test a patch I send you?
>>>>>>>
>>>>>>> Guillaume
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Yes I can.
>>>>>>
>>>>>> Cor
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> Thanks! This is a huge improvement. I have now readable purple text
>>>> against the dark background.
>>>>
>>>
>>> Huh great but I did not intend to make it purple. Can I please have a
>>> screenshot?
>>>
>> Good choice of color for dark schemes. Works well here with
>> Mediterranean (Darkest).
>
>
> This is just (blue + text color)/2...
>
>>
>> I too get something that is (to my eyes) purplish, though I should
>> mention that I'm also running redshift. The color picker says
>> "#6060DF" (or in the whereabouts).
>
>

> Blue then. What about math? And errors (e.g. unencodable characters) ?
>
I the preamble math is fine. Same in the source. Errors are acceptable
(not sure how to trigger unencodable chars though).

Looks good:
http://i.imgur.com/OK2bQpV.png
http://i.imgur.com/m3FdURN.png
http://i.imgur.com/NQQQ9Jz.png

Thanks,
Liviu

Re: lyx and dark color schemes

[Liviu Andronic]

On Wed, Jun 15, 2016 at 5:52 PM, Guillaume Munch  wrote:
> Le 15/06/2016 15:47, Liviu Andronic a écrit :
>>
>> On Wed, Jun 15, 2016 at 3:35 PM, Guillaume Munch  wrote:
>>>
>>> Le 14/06/2016 22:14, Cor Blom a écrit :
>>>>
>>>>
>>>> Op 14-06-16 om 22:21 schreef Guillaume Munch:
>>>>>
>>>>>
>>>>> Le 14/06/2016 21:16, Cor Blom a écrit :
>>>>>>
>>>>>>
>>>>>> Op 14-06-16 om 22:09 schreef Guillaume Munch:
>>>>>>>
>>>>>>>
>>>>>>> Le 14/06/2016 18:44, Cor Blom a écrit :
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Recently I tried lyx with a dark color scheme (breeze-dark  under
>>>>>>>> kde
>>>>>>>> plasma 5). Ihe toolbar icons are problematic, but I know how to fix
>>>>>>>> that
>>>>>>>> (and the oxygen set is not that bad against a dark background). In
>>>>>>>> general I'm happy about it. There is one issue. I don't know whether
>>>>>>>> it's possible and I'm missing something, or not.
>>>>>>>>
>>>>>>>> Under de Documents > Settings, in the preamble part, blue is used
>>>>>>>> for
>>>>>>>> code. Against a dark background this is unreadable. Also in the code
>>>>>>>> view panel, de latex commands are blue, which makes them
>>>>>>>> unreadable. Is
>>>>>>>> that color configurable somewhere? I've searched but can't find the
>>>>>>>> solution.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Cor
>>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Can you compile master and test a patch I send you?
>>>>>>>
>>>>>>> Guillaume
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Yes I can.
>>>>>>
>>>>>> Cor
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> Thanks! This is a huge improvement. I have now readable purple text
>>>> against the dark background.
>>>>
>>>
>>> Huh great but I did not intend to make it purple. Can I please have a
>>> screenshot?
>>>
>> Good choice of color for dark schemes. Works well here with
>> Mediterranean (Darkest).
>
>
> This is just (blue + text color)/2...
>
>>
>> I too get something that is (to my eyes) purplish, though I should
>> mention that I'm also running redshift. The color picker says
>> "#6060DF" (or in the whereabouts).
>
>
> Blue then. What about math? And errors (e.g. unencodable characters) ?
>
Math is OK. I usually just change colours manually in Prefs > Colors.
Same for notes, etc.

The single most unreadable instance though is blue headings like in Beamer:
http://i.imgur.com/zoSqWvX.png

Unfortunately there is no ready way to change this, as it would
require to redefine document classes where these things are hardcoded.

There is also an open ticket for these issues:
http://www.lyx.org/trac/ticket/8325

But I'm not sure there is an easy way to come up with defaults
suitable for both light and dark schemes...


Liviu

Re: lyx and dark color schemes

[Liviu Andronic]

On Wed, Jun 15, 2016 at 3:35 PM, Guillaume Munch  wrote:
> Le 14/06/2016 22:14, Cor Blom a écrit :
>>
>> Op 14-06-16 om 22:21 schreef Guillaume Munch:
>>>
>>> Le 14/06/2016 21:16, Cor Blom a écrit :

 Op 14-06-16 om 22:09 schreef Guillaume Munch:
>
> Le 14/06/2016 18:44, Cor Blom a écrit :
>>
>> Hi,
>>
>> Recently I tried lyx with a dark color scheme (breeze-dark  under kde
>> plasma 5). Ihe toolbar icons are problematic, but I know how to fix
>> that
>> (and the oxygen set is not that bad against a dark background). In
>> general I'm happy about it. There is one issue. I don't know whether
>> it's possible and I'm missing something, or not.
>>
>> Under de Documents > Settings, in the preamble part, blue is used for
>> code. Against a dark background this is unreadable. Also in the code
>> view panel, de latex commands are blue, which makes them
>> unreadable. Is
>> that color configurable somewhere? I've searched but can't find the
>> solution.
>>
>> Thanks,
>>
>> Cor
>>
>
> Hi,
>
> Can you compile master and test a patch I send you?
>
> Guillaume
>
>

 Yes I can.

 Cor


>>>
>>
>> Thanks! This is a huge improvement. I have now readable purple text
>> against the dark background.
>>
>
> Huh great but I did not intend to make it purple. Can I please have a
> screenshot?
>
Good choice of color for dark schemes. Works well here with
Mediterranean (Darkest).

I too get something that is (to my eyes) purplish, though I should
mention that I'm also running redshift. The color picker says
"#6060DF" (or in the whereabouts).

Screen shot here:
http://i.imgur.com/b5gA51x.png

Regards,
Liviu


>

Re: compilation for coverity fails

[Liviu Andronic]

On Thu, Jun 9, 2016 at 4:14 PM, Jean-Marc Lasgouttes  wrote:
> Le 09/06/2016 à 12:22, Liviu Andronic a écrit :
>>>
>>> Are you currently updating the analysis on coverity site?
>>>
>> Yes, uploading build now. Should be up within an hour or so.
>
>
> They are there indeed, thanks. There two new defects, but these are false
> positive. I have changed to code to avoid them.
>
> We are now down to 67 outstanding defects.
> https://scan.coverity.com/projects/4164
>
> Tere are many trivial defects (uninitialized members), and a few tricky ones
> (like loop that only does one iteration :).
>
> To work on it, ask Liviu about access.
>
Following JMarc's and Richard's furious hunting, we're now down to 22
outstanding defects, down from about 200 we had originally during the
first scan in 2015. At least as far as Coverity's checks go, we're
starting to look pretty --- though I understand there are a couple of
problematic cases left that require a close look at the code base.

Liviu


> JMarc

Re: compilation for coverity fails

[Liviu Andronic]

On Thu, Jun 9, 2016 at 12:20 PM, Jean-Marc Lasgouttes
 wrote:
> Le 09/06/2016 à 11:49, Liviu Andronic a écrit :
>>
>> On Thu, Jun 9, 2016 at 10:19 AM, Jean-Marc Lasgouttes
>>  wrote:
>>>
>>>
>>> Le 08/06/2016 à 23:39, Liviu Andronic a écrit :
>>>>
>>>>
>>>> Does anyone know if these error messages point to a problem in our code?
>>>
>>>
>>>
>>> Is this a clean build?
>>>
>> Thank you, that must have been it. After a make distclean, compilation
>> under coverity proceeded smoothly.
>
>
> There is something wrong with our dependencies from time to time, but I am
> not sure what.
>
> Are you currently updating the analysis on coverity site?
>
Yes, uploading build now. Should be up within an hour or so.

Liviu


> JMarc
>

Re: compilation for coverity fails

[Liviu Andronic]

On Thu, Jun 9, 2016 at 10:19 AM, Jean-Marc Lasgouttes
 wrote:
>
> Le 08/06/2016 à 23:39, Liviu Andronic a écrit :
>>
>> Does anyone know if these error messages point to a problem in our code?
>
>
> Is this a clean build?
>
Thank you, that must have been it. After a make distclean, compilation
under coverity proceeded smoothly.

Liviu


> JMarc
>

Re: compilation for coverity fails

[Liviu Andronic]

On Tue, Jun 7, 2016 at 8:08 PM, Liviu Andronic  wrote:

>
> AR liblyxinsets.a
> CXXLD lyx
> liblyxinsets.a(InsetERT.o):(.rodata._ZTVN3lyx8InsetERTE[_ZTVN3lyx8InsetERTE]+0x230):
> undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
> liblyxinsets.a(InsetIndex.o):(.rodata._ZTVN3lyx10InsetIndexE[_ZTVN3lyx10InsetIndexE]+0x230):
> undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
> liblyxinsets.a(InsetIPAMacro.o):(.rodata._ZTVN3lyx12InsetIPADecoE[_ZTVN3lyx12InsetIPADecoE]+0x230):
> undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
> liblyxinsets.a(InsetWrap.o):(.rodata._ZTVN3lyx9InsetWrapE[_ZTVN3lyx9InsetWrapE]+0x230):
> undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
> liblyxinsets.a(InsetCaptionable.o):(.rodata._ZTVN3lyx16InsetCaptionableE[_ZTVN3lyx16InsetCaptionableE]+0x230):
> undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
> collect2: error: ld returned 1 exit status
> make[4]: *** [lyx] Error 1
>

Does anyone know if these error messages point to a problem in our code?

Regards,
Liviu

Re: Tarballs for LyX 2.2.0 are on FTP

[Liviu Andronic]

On Wed, Jun 8, 2016 at 10:14 PM, Guillaume Munch  wrote:
>
> Le 08/06/2016 20:48, Pavel Sanda a écrit :
>>
>> Guillaume Munch wrote:
>>>
>>> Here's what I suggest. Let's do, on a trial basis for the duration of
>>> 2.3dev, a branch that mirrors master but inserts patches to disable the
>>> input and output of new file-format features (as well as layout changes,
>>> etc.) after each file-format change. We would see if the idea works out.
>>>
>>> I was going to do something like this anyway for myself, so I propose to
>>> take care of it until it gains some momentum. At first we could just
>>> make nightlies out of it for Ubuntu.
>>>
>>> One roadblock that I am expecting is that the author of the original
>>> file format change knows better than me how to block it, but in case of
>>> trouble I can ask for advice. I plan to include the patches responsible
>>> for file format changes and patch them afterwards, because otherwise I
>>> expect the code to diverge too much. If at some point it no longer works
>>> then I will stop.
>>>
>>> I will call the branch ?unstable?.
>>>
>>> Agreement? Suggestions?
>>
>>
>> So what is the goal here. Jut to get aditional testing from interested
>> parties or to make release from this branch at the end?
>
>
> In a first time the goal would be to have nightlies, if Liviu agrees that we 
> reuse his infrastructure.
>
Generally I'm not convinced that spreading testing over two types of
master builds is a good idea, especially since we do not have such
testing manpower anyway. The problem with bleeding edge master is not
confined to fileformat changes (and in any case as it had been
suggested you can still export to 2.prev anyway) --- master will
always contain regressions and other nastiness, which is more likely
to keep testers at bay, at least those who use LyX for production.
And, for me at least, it feels strange to test neutered bleeding edge
code --- seems like a way to keep testers from trying out latest
fileformat changes and associated complications. (Imagine for instance
if the radical 2.2.0dev beamer modifications hadn't gotten the
attention they deserved...)

We can of course set up daily builds using this third branch, but I
wouldn't put them in the lyx-devel PPAs. Given that the packaging
arrangements are already ready for daily builds (though I still have
to prepare the 2.3 builds, probably towards the end of the month),
setting up a new recipe/PPA should be very easy and I'll gladly walk
you through it.

Regards,
Liviu


> If the experience is positive, then we can discuss again your idea of having 
> official intermediate releases of master without file format changes, after 
> 2.3 is released.
>
>

compilation for coverity fails

[Liviu Andronic]

Dear all,
I am trying to build LyX for analysis by coverity but compilation fails.
(Normal compilation completes fine.)

geek@liv-inspiron:~/Build/Devel/lyx$ cov-build --dir cov-int make -j 3
Coverity Build Capture (64-bit) version 7.6.0 on Linux 3.13.0-24-generic
x86_64
Internal version numbers: 9b77a50df0 p-harmony-push-21098.563

[...]

CXX mathed/MathSupport.o
CXX insets/ExternalSupport.o
CXX insets/ExternalTransforms.o
CXX insets/RenderButton.o
CXX insets/Inset.o
CXX insets/InsetArgument.o
CXX insets/InsetBibtex.o
CXX insets/InsetBox.o
CXX insets/InsetBranch.o
CXX insets/InsetCaption.o
CXX insets/InsetCitation.o
CXX insets/InsetCollapsable.o
CXX insets/InsetCommand.o
CXX insets/InsetCommandParams.o
CXX insets/InsetExternal.o
CXX insets/InsetFlex.o
CXX insets/InsetFloat.o
CXX insets/InsetFoot.o
CXX insets/InsetFootlike.o
CXX insets/InsetGraphicsParams.o
CXX insets/InsetGraphics.o
CXX insets/InsetInclude.o
CXX insets/InsetInfo.o
CXX insets/InsetIPA.o
CXX insets/InsetLabel.o
CXX insets/InsetLayout.o
CXX insets/InsetListings.o
CXX insets/InsetMarginal.o
CXX insets/InsetNewpage.o
CXX insets/InsetNote.o
CXX insets/InsetPhantom.o
CXX insets/InsetPreview.o
CXX insets/InsetRef.o
CXX insets/InsetScript.o
CXX insets/InsetSeparator.o
CXX insets/InsetSpace.o
CXX insets/InsetSpecialChar.o
CXX insets/InsetTabular.o
CXX insets/InsetText.o
CXX Compare.o
CXX HunspellChecker.o
CXX PrinterParams.o
AR liblyxcore.a
AR liblyxgraphics.a
AR liblyxmathed.a
AR liblyxinsets.a
CXXLD lyx
liblyxinsets.a(InsetERT.o):(.rodata._ZTVN3lyx8InsetERTE[_ZTVN3lyx8InsetERTE]+0x230):
undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
liblyxinsets.a(InsetIndex.o):(.rodata._ZTVN3lyx10InsetIndexE[_ZTVN3lyx10InsetIndexE]+0x230):
undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
liblyxinsets.a(InsetIPAMacro.o):(.rodata._ZTVN3lyx12InsetIPADecoE[_ZTVN3lyx12InsetIPADecoE]+0x230):
undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
liblyxinsets.a(InsetWrap.o):(.rodata._ZTVN3lyx9InsetWrapE[_ZTVN3lyx9InsetWrapE]+0x230):
undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
liblyxinsets.a(InsetCaptionable.o):(.rodata._ZTVN3lyx16InsetCaptionableE[_ZTVN3lyx16InsetCaptionableE]+0x230):
undefined reference to `lyx::InsetCollapsable::clickable(int, int) const'
collect2: error: ld returned 1 exit status
make[4]: *** [lyx] Error 1
make[4]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/geek/Build/Devel/lyx/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/geek/Build/Devel/lyx'
make: *** [all] Error 2
[WARNING] Build command make -j 3 exited with code 2. Please verify that
the build completed successfully.
161 C/C++ compilation units (100%) are ready for analysis
For more details, please look at:
/home/geek/Build/Devel/lyx/cov-int/build-log.txt

Are the *undefined reference* messages above an issue? I'm surprised
because normal compilation (outside coverity) works fine.

Regards,
Liviu

Re: Tarballs for LyX 2.2.0 are on FTP

[Liviu Andronic]

On Tue, Jun 7, 2016 at 12:10 AM, Andrew Parsloe  wrote:
> On 7/06/2016 9:50 a.m., Richard Heck wrote:
>>
>> On 06/06/2016 03:33 PM, Georg Baum wrote:
>>>
>>> Jean-Marc Lasgouttes wrote:
>>>
 Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
>
> Yet, most of the file format changes are very simple. I wonder whether
> one could introduce a single compilation variable to disable them,
> and ask developers to enclose file-format-specific code between the
> corresponding #ifdefs. (For instance in my last file format change all
> that was needed to be enclosed was the parsing code.) This would allow
> the release of "master versions without file format changes", either as
> nightlies or as official "x.5" versions as Pavel suggested by Pavel in
> another message (without having to maintain three branches in
> parallel).

 This looks too complicated to me. And eventually there will be changes
 that cannot be treated like that, and all the previous work on small 
 changes
 will be useless.

 Note that that stable nightlies could be updated with lyx2lyx code for
 new master versions in parallel with master.
>>>
>>> Or we could add a mode that calls lyx2lyx automatically after saving, so
>>> that effectively the master version would use the old file format. This
>>> would probably work fine as long as no new features are used.
>>
>> Yes, but do we want to warn people then not to use new features? I think
>> it would just confuse people for us to tell them to test master but not
>> to use some new features if they want to be able to go back to stable.
>>
>> Richard
>>
> As a potential user-tester I've followed this discussion with interest. I
> can't imagine downloading and installing LyX daily, but I can imagine doing
> this each month and using the resulting installation as my working LyX (as I
> did for the alphas and betas of 2.2.0), therefore with all features turned
> on and potential unreadability in earlier versions.
>
This is how I often use the devel builds as well --- switch to a devel
build and work with it for some time. I think other testers broadly do
the same when there is some new killer feature in master, but it isn't
clear when a new release is due.

Liviu


> Andrew
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

Re: One official build system?

[Liviu Andronic]

On Mon, Jun 6, 2016 at 6:56 PM, Kornel Benko  wrote:
> Am Sonntag, 5. Juni 2016 um 20:34:38, schrieb Liviu Andronic 
> 
>> On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
>> > Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
>> >> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
>> >> 
>> >> > Kornel Benko wrote:
>> >> >
>> > ...
>> >> > The remaining directories from the second list would be located as 
>> >> > follows:
>> >> >
>> >> > bin:$prefix/bin
>> >> > fonts:  $datarootdir/fonts/truetype/$package
>> >
>> > I am not sure about this one. Are there clashes with
>> > the same files installed by different lyx-version?
>> > How should latex select the correct data?
>> >
>> On Ubuntu for the fonts-lyx packages I simply make them conflict with
>> each other, meaning that the user can install only one on the same
>> system (e.g. fonts-lyx or fonts-lyx2.2).
>>
>


> Unfortunately cmake is not able yet to produce more than one debian package. 
> Recently started
> discussions to support components for .rpm, but .deb is not that far.
> And we have more platforms.
>
As far as my requirements go, I do not need cmake to output debian
packages --- Launchpad and Debian tools take care of that. I only need
cmake to install packages in expected directories with customizable
paths (as we discussed earlier). So I don't think this is an issue.

Liviu


>>
>> >> > locale: $datarootdir/locale
>> >> > tex:$datarootdir/texmf/tex/latex/$package
>> >
>> > Same here.
>> >
>> Not sure what happens in this case, though.
>>
>
> If we could suffix them too ...
>
>> Liviu
>>
>>
>
> Kornel

Re: One official build system?

[Liviu Andronic]

On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
> Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
>> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
>> 
>> > Kornel Benko wrote:
>> >
> ...
>> > The remaining directories from the second list would be located as follows:
>> >
>> > bin:$prefix/bin
>> > fonts:  $datarootdir/fonts/truetype/$package
>
> I am not sure about this one. Are there clashes with
> the same files installed by different lyx-version?
> How should latex select the correct data?
>
On Ubuntu for the fonts-lyx packages I simply make them conflict with
each other, meaning that the user can install only one on the same
system (e.g. fonts-lyx or fonts-lyx2.2).




>> > locale: $datarootdir/locale
>> > tex:$datarootdir/texmf/tex/latex/$package
>
> Same here.
>
Not sure what happens in this case, though.


Liviu


> Kornel



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: One official build system?

[Liviu Andronic]

On Sun, Jun 5, 2016 at 4:20 PM, Georg Baum
 wrote:
> Kornel Benko wrote:
>
>> OK, starting on the list first. I can only comment on the cmake part.
>>
>> [A] detection of  external  dependencies
>> cmake does full detection IMHO
>> [B] create .rpm
>> cmake creates rpm, deb,
>> [E] create window package
>> don't know, we should ask Peter
>> [I] Reliability
>> why is scons higher then autotools?
>> cmake not reliable?
>> [J] Supported platforms
>> cmake supports all our platforms IMHO
>
> This is an old table, I did not look at it (I re-used an existing page with
> a suitable name).
>
>> Commandline arguments for autotools and cmake (arguments for cmake)
>> custom archiver  -DCMAKE_AR=
>> custom assemble   -DCMAKE_AS=
>> custom C compiler  -DCMAKE_CXX_COMPILER=
>> C++ runtime library   -DLYX_STDLIB_DEBUG=ON
>> included boost   -DLYX_EXTERNAL_BOOST=OFF
>> included hunspell  -DLYX_3RDPARTY_BUILD=ON
>> included zlib  -DLYX_3RDPARTY_BUILD=ON
>> installation prefix  -DCMAKE_INSTALL_PREFIX=
>> version suffixin work
>> verbose compiler output -DLYX_QUIET=OFF
>
> Thanks.
>
>> I started the work. But I have to know, what should be affected by the
>> suffix. Suffix = xy
>> 1.) Installations directory (probably not)
>> 2.) Environment variables (like LYX_USERDIR_xy)
>> 3.) Package name
>> 4.) Program suffixes (lyx2.3.dev)
>> 5.) Data directory (for lyx-system-lib-dir)
>> 6.) Binary dir
>
> The same what is affected by autotools --with-version-suffix ;-)
>
+1

At least on Ubuntu the package name is controlled by Debian packaging,
so this isn't something we should worry about. What is important in my
limited experience is to have binaries with appropriate suffix, the
various data dirs with appropriate suffix (including the ~./lyx2.3.dev
dir).

Liviu


> 2.) to 4.) definitely yes. What is the difference between 1 and 6)? My guess
> would be that this should not be affected.
>
>
> Georg
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: One official build system?

[Liviu Andronic]

On Sat, Jun 4, 2016 at 9:55 AM, Georg Baum
 wrote:
> One thing I noticed recently is the
> version suffix: Which autotools you can use an arbitrary one, with cmake you
> can only toggle between a predefined one or none at all, which is a problem
> if you want to compare two different builds of the same version with
> separate configurations (e.g. qt4/qt5 or different compiler settings).
>
If moving to cmake definitively would imply losing version suffix
functionality, this would be a big issue for my packaging arrangements
for Ubuntu builds.

Right now I keep master and branch daily builds (as well as
pre-releases) completely independent from stable LyX packages, which
allows people to blissfully install both stable and bleeding edge
versions on the same system, without worrying of corrupting their
production environment. Losing this will probably imply that we can
install only one build at a time on a given system, which will reduce
the testing opportunities for bleeding edge code

Liviu


>
>
> Georg
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Tarballs for LyX 2.2.0 are on FTP

[Liviu Andronic]

On Fri, Jun 3, 2016 at 2:02 PM, Jean-Marc Lasgouttes  wrote:
> Le 31/05/2016 à 22:26, Georg Baum a écrit :
>>
>> We need to decide: Either have a fixed schedule, and an unknown feature
>> set
>> of the next release, or a fixed feature set, and an unknown schedule. We
>> do
>> not have enough man power for defining both a fixed feature set and a
>> fixed
>> release schedule.
>
>
> I prefer the fixed schedule. We never know exactly when starting a release
> cycle what features will happen or not. But we can enforce when the release
> will happen.
>
I too would favour a fixed schedule. Have a planned ~1 year release
cycle (instead of the 2-2.5 years we currently have, on average), and
start the release process and discussing tagging alpha some 6-8 months
into the cycle. This will help avoid burn out for devels and dragging
new features in trunk for longer than necessary, and avoid too much
uncertainty on when the release will actually happen. This will also
make it possible to make fileformat changes more often than we now do,
and bring about serious testing of trunk (with alpha and beta
releases) by end users less than a year since major features were
introduced on GIT.



>> - Have a build server that does automatic builds on a regular basis for
>> all
>> three platforms (Linux, OS X, windows) and makes binary packages and build
>> logs available.
>
>
> Do you have a particular service in mind? I agree that this would be nifty.
>
We already have nightly builds for Ubuntu Linux:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

It's been running for couple of years (probably all through the 2.2
development cycle), though I'm not sure it's made much of an impact in
terms of testing and bug reports. (I still have to update the
packaging arrangements for 2.3dev, but it should be up and running
"soon".)


Liviu





-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: build requirements for Qt5 build

[Liviu Andronic]

On Tue, May 31, 2016 at 1:54 PM, Jean-Marc Lasgouttes
 wrote:
> Le 31/05/2016 à 13:24, Liviu Andronic a écrit :
>>
>> On Tue, May 31, 2016 at 1:04 PM, Jean-Marc Lasgouttes
>>  wrote:
>>>
>>> Le 31/05/2016 à 12:06, Liviu Andronic a écrit :
>>>>
>>>>
>>>> 'moc' it seems:
>>>> http://packages.ubuntu.com/xenial/amd64/qtbase5-dev-tools/filelist
>>>
>>>
>>>
>>> And what is in /usr/bin?
>>>
>> Not the same version of Qt (and on my own machine), I have
>> qtbase5-dev-tools installed. In /usr/bin I see this:
>
>
> It looks like installing qt5-default  helps.
>
This worked, thanks. Looks like the required Qt5 packages on Ubuntu are:
qtbase5-dev, libqt5svg5-dev, qt5-default

Regards,
Liviu


> I am not sure whether it is
> still possible to compile for qt4 after that, though...
>
> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: build requirements for Qt5 build

[Liviu Andronic]

On Tue, May 31, 2016 at 1:04 PM, Jean-Marc Lasgouttes
 wrote:
> Le 31/05/2016 à 12:06, Liviu Andronic a écrit :
>>
>> 'moc' it seems:
>> http://packages.ubuntu.com/xenial/amd64/qtbase5-dev-tools/filelist
>
>
> And what is in /usr/bin?
>
Not the same version of Qt (and on my own machine), I have
qtbase5-dev-tools installed. In /usr/bin I see this:

geek@liv-inspiron:~$ ls /usr/bin/moc -l
lrwxrwxrwx 1 root root 9 Feb 19 2014 /usr/bin/moc -> qtchooser

geek@liv-inspiron:~$ /usr/bin/moc --help
Usage: /usr/lib/x86_64-linux-gnu/qt5/bin/moc [options] [header-file]
[@option-file]
Qt Meta Object Compiler version 67 (Qt 5.2.1)
[...]

geek@liv-inspiron:~$ ls /usr/bin/qtchooser -l
-rwxr-xr-x 1 root root 31328 Feb 19 2014 /usr/bin/qtchooser


geek@liv-inspiron:~$ /usr/bin/qtchooser -l
4
5
default
qt4-i386-linux-gnu
qt4-x86_64-linux-gnu
qt4
qt5-x86_64-linux-gnu
qt5



> JMarc
>
>
>> /usr/lib/x86_64-linux-gnu/qt5/bin/moc
>> /usr/lib/x86_64-linux-gnu/qt5/bin/qdbuscpp2xml
>> /usr/lib/x86_64-linux-gnu/qt5/bin/qdbusxml2cpp
>> /usr/lib/x86_64-linux-gnu/qt5/bin/qdoc
>> /usr/lib/x86_64-linux-gnu/qt5/bin/qlalr
>> /usr/lib/x86_64-linux-gnu/qt5/bin/rcc
>> /usr/lib/x86_64-linux-gnu/qt5/bin/syncqt.pl
>> /usr/lib/x86_64-linux-gnu/qt5/bin/uic
>> /usr/share/doc/qtbase5-dev-tools/LGPL_EXCEPTION.txt
>> /usr/share/doc/qtbase5-dev-tools/changelog.Debian.gz
>> /usr/share/doc/qtbase5-dev-tools/copyright
>> /usr/share/man/man1/moc-qt5.1.gz
>
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: build requirements for Qt5 build

[Liviu Andronic]

On Tue, May 31, 2016 at 12:01 PM, Jean-Marc Lasgouttes
 wrote:
> Le 31/05/2016 à 11:57, Liviu Andronic a écrit :
>>>
>>> You do not need any qt4 stuff. It may be that moc is named moc5 or
>>> something
>>> for qt5. Or that moc is a link to something else.
>>>
>> Just checked and Qt5 moc comes with qtbase5-dev-tools, which is
>> automatically pulled by qtbase5-dev.
>>
>> For some reason the correct moc compiler is still not detected, though.
>
>
> What is te name of the moc binary for qt5?
>
'moc' it seems:
http://packages.ubuntu.com/xenial/amd64/qtbase5-dev-tools/filelist

/usr/lib/x86_64-linux-gnu/qt5/bin/moc
/usr/lib/x86_64-linux-gnu/qt5/bin/qdbuscpp2xml
/usr/lib/x86_64-linux-gnu/qt5/bin/qdbusxml2cpp
/usr/lib/x86_64-linux-gnu/qt5/bin/qdoc
/usr/lib/x86_64-linux-gnu/qt5/bin/qlalr
/usr/lib/x86_64-linux-gnu/qt5/bin/rcc
/usr/lib/x86_64-linux-gnu/qt5/bin/syncqt.pl
/usr/lib/x86_64-linux-gnu/qt5/bin/uic
/usr/share/doc/qtbase5-dev-tools/LGPL_EXCEPTION.txt
/usr/share/doc/qtbase5-dev-tools/changelog.Debian.gz
/usr/share/doc/qtbase5-dev-tools/copyright
/usr/share/man/man1/moc-qt5.1.gz




-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: build requirements for Qt5 build

[Liviu Andronic]

On Tue, May 31, 2016 at 11:50 AM, Jean-Marc Lasgouttes
 wrote:
> Le 31/05/2016 à 11:47, Liviu Andronic a écrit :
>
>>>> So either it is a Qt4 moc and qt4 is not corectly installed, or
>>>> something
>>>> else is wrong.
>>>>
>>> Since I'm building only for Qt5 (so using qtbase5-dev), should I also
>>> install Qt4 development libraries (i.e. libqt4-dev)?
>>>
>> I'm definitely not getting the right moc files. I tried adding
>> libqt4-dev, and now the compilation error message is as follows:
>>
>> https://launchpadlibrarian.net/262539787/buildlog_ubuntu-xenial-amd64.lyx_2.2.0-2~xenial~ppa8_BUILDING.txt.gz
>> == The found moc compiler is for Qt 4.8.7 but the Qt library version is
>> 5.5.1.
>>
>> Not sure where to go from here.
>
>
> You do not need any qt4 stuff. It may be that moc is named moc5 or something
> for qt5. Or that moc is a link to something else.
>
Just checked and Qt5 moc comes with qtbase5-dev-tools, which is
automatically pulled by qtbase5-dev.

For some reason the correct moc compiler is still not detected, though.


Liviu


> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: build requirements for Qt5 build

[Liviu Andronic]

On Tue, May 31, 2016 at 11:38 AM, Liviu Andronic  wrote:
> On Tue, May 31, 2016 at 11:31 AM, Jean-Marc Lasgouttes
>  wrote:
>> Le 31/05/2016 à 11:21, Liviu Andronic a écrit :
>>>>
>>>> If it is, you may need to add something
>>>> to your include path. Or we may need to use something more reasonable
>>>> than
>>>>   #include 
>>>>   #include 
>>>>
>>>> At least qstring.h seems very old-fashionned.
>>>>
>>> I've added libqt5svg5-dev and at least this part is now working:
>>
>>
>> I'd still like to know about qglobal.h location.
>>
> Since I'm installing qtbase5-dev, I suspect it will end up here
> (depending on platform):
> http://packages.ubuntu.com/search?searchon=contents&keywords=qglobal.h&mode=exactfilename&suite=xenial&arch=any
>
> /usr/include/i386-linux-gnu/qt5/QtCore/qglobal.h
> /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h
>
>
>
>
>>>
>>> https://launchpadlibrarian.net/262536549/buildlog_ubuntu-xenial-amd64.lyx_2.2.0-2~xenial~ppa5_BUILDING.txt.gz
>>> checking for moc-qt5... no
>>> checking for moc... /usr/bin/moc
>>
>>
>> When compiling, moc says:
>>
>> /usr/bin/moc  -o moc_Compare.cpp ../../src/Compare.h
>> moc: could not find a Qt installation of ''
>>

>> So either it is a Qt4 moc and qt4 is not corectly installed, or something
>> else is wrong.
>>
> Since I'm building only for Qt5 (so using qtbase5-dev), should I also
> install Qt4 development libraries (i.e. libqt4-dev)?
>
I'm definitely not getting the right moc files. I tried adding
libqt4-dev, and now the compilation error message is as follows:
https://launchpadlibrarian.net/262539787/buildlog_ubuntu-xenial-amd64.lyx_2.2.0-2~xenial~ppa8_BUILDING.txt.gz
== The found moc compiler is for Qt 4.8.7 but the Qt library version is 5.5.1.

Not sure where to go from here.

Liviu


> Liviu
>
>
>> JMarc
>>
>
>
>
> --
> Do you think you know what math is?
> http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
> Or what it means to be intelligent?
> http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
> Think again:
> http://www.ideasroadshow.com/library



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: build requirements for Qt5 build

[Liviu Andronic]

On Tue, May 31, 2016 at 11:31 AM, Jean-Marc Lasgouttes
 wrote:
> Le 31/05/2016 à 11:21, Liviu Andronic a écrit :
>>>
>>> If it is, you may need to add something
>>> to your include path. Or we may need to use something more reasonable
>>> than
>>>   #include 
>>>   #include 
>>>
>>> At least qstring.h seems very old-fashionned.
>>>
>> I've added libqt5svg5-dev and at least this part is now working:
>
>
> I'd still like to know about qglobal.h location.
>
Since I'm installing qtbase5-dev, I suspect it will end up here
(depending on platform):
http://packages.ubuntu.com/search?searchon=contents&keywords=qglobal.h&mode=exactfilename&suite=xenial&arch=any

/usr/include/i386-linux-gnu/qt5/QtCore/qglobal.h
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h




>>
>> https://launchpadlibrarian.net/262536549/buildlog_ubuntu-xenial-amd64.lyx_2.2.0-2~xenial~ppa5_BUILDING.txt.gz
>> checking for moc-qt5... no
>> checking for moc... /usr/bin/moc
>
>
> When compiling, moc says:
>
> /usr/bin/moc  -o moc_Compare.cpp ../../src/Compare.h
> moc: could not find a Qt installation of ''
>
> So either it is a Qt4 moc and qt4 is not corectly installed, or something
> else is wrong.
>
Since I'm building only for Qt5 (so using qtbase5-dev), should I also
install Qt4 development libraries (i.e. libqt4-dev)?

Liviu


> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: build requirements for Qt5 build

[Liviu Andronic]

 an

On Tue, May 31, 2016 at 11:11 AM, Jean-Marc Lasgouttes
 wrote:
> Le 31/05/2016 à 11:06, Jean-Marc Lasgouttes a écrit :
>>
>> Le 31/05/2016 à 10:57, Liviu Andronic a écrit :
>>>>
>>>> Could we see your config.log?
>>>>
>>> I think it's automatically dumped here after the configure error:
>>>
>>> https://launchpadlibrarian.net/262531359/buildlog_ubuntu-xenial-i386.lyx_2.2.0-2~xenial~ppa3_BUILDING.txt.gz
>>>
>>
>> I see complaints about missing Qt5Svg. Did you install the necessary
>> packages?
>
>
> This complaint is in the part that relies on pkg-config.
>
> Then configure tries to find Qt in the good old way, and qglobal.h cannot be
> found. Is it somewhere on your disk?
>
I am building on Launchpad which generates a fresh, minimal Ubuntu
install. So it will only detect what the various packages install on
the image.


> If it is, you may need to add something
> to your include path. Or we may need to use something more reasonable than
>   #include 
>   #include 
>
> At least qstring.h seems very old-fashionned.
>
I've added libqt5svg5-dev and at least this part is now working:

https://launchpadlibrarian.net/262536549/buildlog_ubuntu-xenial-amd64.lyx_2.2.0-2~xenial~ppa5_BUILDING.txt.gz
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for QT_CORE... yes
checking for QT_FRONTEND... yes
checking whether Qt uses the X Window system... yes
checking for moc-qt5... no
checking for moc... /usr/bin/moc
checking for uic-qt5... no
checking for uic... /usr/bin/uic
checking for rcc-qt5... no
checking for rcc... /usr/bin/rcc


And configure ends up gracefully:
Configuration
Host type: x86_64-pc-linux-gnu
Special build flags: build=release warnings c++11 std-regex use-aspell
use-enchant use-hunspell
C++ Compiler: g++ (5.3.1)
C++ Compiler flags: -Wall -Wextra -std=c++11 -fPIC -O2
-Wno-deprecated-declarations
C++ Compiler user flags:
Linker flags:
Linker user flags:
Qt Frontend:
Qt version: 5.5.1
Packaging: posix
LyX binary dir: /usr/bin
LyX files dir: /usr/share/lyx


=== The following minor problems have been detected by configure.
=== Please check the messages below before running 'make'.
=== (see the section 'Problems' in the INSTALL file)

== The found moc compiler is for Qt moc: could not find a Qt
installation of '' but the Qt library version is 5.5.1.


Though I'm not sure what this last message means, and compilation itself fails.

Liviu


> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: build requirements for Qt5 build

[Liviu Andronic]

On Tue, May 31, 2016 at 10:55 AM, Jean-Marc Lasgouttes
 wrote:
> Le 31/05/2016 à 10:53, Liviu Andronic a écrit :
>>>>
>>>> checking for QT_CORE... yes
>>>> checking for QT_FRONTEND... checking for X... libraries , headers
>>>> checking for gethostbyname... yes
>>>> checking for connect... yes
>>>> checking for remove... yes
>>>> checking for shmat... yes
>>>> checking for IceConnectionNumber in -lICE... yes
>>>> checking for Qt library name... failed
>>>> configure: error: cannot compile a simple Qt executable. Check you
>>>> have the right $QTDIR.
>>>>
>>>> Am I missing something else?
>
>
> Could we see your config.log?
>
I think it's automatically dumped here after the configure error:
https://launchpadlibrarian.net/262531359/buildlog_ubuntu-xenial-i386.lyx_2.2.0-2~xenial~ppa3_BUILDING.txt.gz


See line:
==> config.log <==



Liviu


> JMarc



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: build requirements for Qt5 build

[Liviu Andronic]

On Tue, May 31, 2016 at 10:50 AM, Kornel Benko  wrote:
> Am Dienstag, 31. Mai 2016 um 10:33:46, schrieb Liviu Andronic 
> 
>> On Tue, May 31, 2016 at 10:21 AM, Kornel Benko  wrote:
>> > Am Dienstag, 31. Mai 2016 um 10:04:54, schrieb Liviu Andronic 
>> > 
>> >> Dear all,
>> >> I am trying to build 2.2.0 using Qt5 on Ubuntu 16.04 but fail. I've
>> >> added qtbase5-dev and qtdeclarative5-dev to the build deps, but for
>> >> some reason this seems to be insufficient and configure ends up in an
>> >> error:
>> >>
>> >> https://launchpadlibrarian.net/262523166/buildlog_ubuntu-xenial-amd64.lyx_2.2.0-2~xenial~ppa2_BUILDING.txt.gz
>> >>
>> >> checking for QT_CORE... yes
>> >> checking for QT_FRONTEND... checking for X... libraries , headers
>> >> checking for gethostbyname... yes
>> >> checking for connect... yes
>> >> checking for remove... yes
>> >> checking for shmat... yes
>> >> checking for IceConnectionNumber in -lICE... no
>> >> checking for Qt library name... failed
>> >> configure: error: cannot compile a simple Qt executable. Check you
>> >> have the right $QTDIR.
>> >>
>> >> Should $QTDIR somehow be explicitly passed to configure?
>> >
>> > QTDIR is environment variable, but as other libs QT libs are found, you 
>> > don't neet to set it.
>> >
>> > But from your log, you are missing libICE.
>> > Package libice-dev ...
>> >
>>
>> Thanks. I add the dep but I'm getting the same error:
>> https://launchpadlibrarian.net/262531359/buildlog_ubuntu-xenial-i386.lyx_2.2.0-2~xenial~ppa3_BUILDING.txt.gz
>>
>> checking for QT_CORE... yes
>> checking for QT_FRONTEND... checking for X... libraries , headers
>> checking for gethostbyname... yes
>> checking for connect... yes
>> checking for remove... yes
>> checking for shmat... yes
>> checking for IceConnectionNumber in -lICE... yes
>> checking for Qt library name... failed
>> configure: error: cannot compile a simple Qt executable. Check you
>> have the right $QTDIR.
>>
>> Am I missing something else?
>>
>> Regards,
>> Liviu
>

> Did you run ./autogen.sh prior to configure?
>
No, I didn't. But is it necessary for release tarballs? For the Qt4
builds of 2.2.0 I'm not running ./autogen.sh either, but compilation
proceeds as expected... So maybe we're missing something in our Qt5
setup...

Liviu


> I am getting totally different output.
> ...
> checking for QT_CORE... yes
> checking for QT_FRONTEND... yes
> checking whether Qt uses the X Window system... yes
> checking for moc-qt5... no
> checking for moc... /usr/BUILD/BuildQt5/5.6/gcc_64/bin/moc
> checking for uic-qt5... no
> checking for uic... /usr/BUILD/BuildQt5/5.6/gcc_64/bin/uic
> checking for rcc-qt5... no
> checking for rcc... /usr/BUILD/BuildQt5/5.6/gcc_64/bin/rcc
> checking whether NLS is requested... yes
> ...
>
> Kornel
>>
>>
>> >> Regards,
>> >> Liviu
>> >
>> > Kornel
>>
>>
>>
>>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: build requirements for Qt5 build

[Liviu Andronic]

On Tue, May 31, 2016 at 10:21 AM, Kornel Benko  wrote:
> Am Dienstag, 31. Mai 2016 um 10:04:54, schrieb Liviu Andronic 
> 
>> Dear all,
>> I am trying to build 2.2.0 using Qt5 on Ubuntu 16.04 but fail. I've
>> added qtbase5-dev and qtdeclarative5-dev to the build deps, but for
>> some reason this seems to be insufficient and configure ends up in an
>> error:
>>
>> https://launchpadlibrarian.net/262523166/buildlog_ubuntu-xenial-amd64.lyx_2.2.0-2~xenial~ppa2_BUILDING.txt.gz
>>
>> checking for QT_CORE... yes
>> checking for QT_FRONTEND... checking for X... libraries , headers
>> checking for gethostbyname... yes
>> checking for connect... yes
>> checking for remove... yes
>> checking for shmat... yes
>> checking for IceConnectionNumber in -lICE... no
>> checking for Qt library name... failed
>> configure: error: cannot compile a simple Qt executable. Check you
>> have the right $QTDIR.
>>
>> Should $QTDIR somehow be explicitly passed to configure?
>
> QTDIR is environment variable, but as other libs QT libs are found, you don't 
> neet to set it.
>
> But from your log, you are missing libICE.
> Package libice-dev ...
>

Thanks. I add the dep but I'm getting the same error:
https://launchpadlibrarian.net/262531359/buildlog_ubuntu-xenial-i386.lyx_2.2.0-2~xenial~ppa3_BUILDING.txt.gz

checking for QT_CORE... yes
checking for QT_FRONTEND... checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for Qt library name... failed
configure: error: cannot compile a simple Qt executable. Check you
have the right $QTDIR.

Am I missing something else?

Regards,
Liviu



>> Regards,
>> Liviu
>
> Kornel



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

build requirements for Qt5 build

[Liviu Andronic]

Dear all,
I am trying to build 2.2.0 using Qt5 on Ubuntu 16.04 but fail. I've
added qtbase5-dev and qtdeclarative5-dev to the build deps, but for
some reason this seems to be insufficient and configure ends up in an
error:

https://launchpadlibrarian.net/262523166/buildlog_ubuntu-xenial-amd64.lyx_2.2.0-2~xenial~ppa2_BUILDING.txt.gz

checking for QT_CORE... yes
checking for QT_FRONTEND... checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... no
checking for Qt library name... failed
configure: error: cannot compile a simple Qt executable. Check you
have the right $QTDIR.

Should $QTDIR somehow be explicitly passed to configure?

Regards,
Liviu

-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: InsetLayout Argument Delimiters

[Liviu Andronic]

On Tue, May 17, 2016 at 11:08 AM, Jürgen Spitzmüller  wrote:
> Am Montag, den 16.05.2016, 16:21 -0400 schrieb Richard Heck:
>>
>> Suppose I do something like this:
>>
>> InsetLayout Flex:Test
>> LyXType custom
>> LatexName   test
>> LatexType   command
>> Decoration  classic
>> LabelString test
>> LeftDelim [
>> RightDelim ]
>> End
>>
>> I'd expect to get as output something like:
>>
>> \test[This is the argument]
>>
>> In fact, what I get is:
>>
>> \test{[This is the argument]}
>>
>> This looks like a bug.
>>
>> Mostly, LeftDelim and RightDelim seem to be used with other arguments
>> besides the default one.
>
> I think it was intentional when it was implemented (these delims in the
> main layout, as opposed to the argument, were introduced mainly for the
> chunk inset, that is, for environments).
>
> But I agree that it should be as you expect it. I stumbled on it myself
> when I was trying to define a macro with only an optional argument,
> which is currently not possible.
>
> So it should be fixed. However, it would be a layout format change,
> since previous definitions that expect the outer braces should probably
> been accounted for.
>
Is it too late in the release process to entertain this for 2.2.0?

Liviu


> Jürgen
>
>>
>> Richard
>>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: 2.2.0rc1 update

[Liviu Andronic]

On Sat, Apr 9, 2016 at 9:48 AM, Scott Kostyshak  wrote:
>
> Dear all,
>
> 2.2.0rc1 is right around the corner. The final changes for layout
> translations have been committed, we've agreed to stop the layout
> discussion for now after good progress, and one more layout commit is
> expected to go in.
>
> If there is an urgent issue that I've forgotten about that requires
> attention for rc1, please let me know now.
>
For the second time this week I get daily builds compilation error:

https://launchpadlibrarian.net/252995163/buildlog_ubuntu-trusty-i386.lyx2.2_2.2.0~git20160409~ubuntu14.04.1_BUILDING.txt.gz

make[5]: Entering directory `/«PKGBUILDDIR»/build-tree/lib'
GEN lyx2.2.desktop
make[5]: *** No rule to make target `templates/aastex.lyx', needed by
`all-am'. Stop.

Does master compile now?

Liviu


> I'm planning to follow standard practice of specifying the number of
> minor versions of 2.1 to 5, as below.
>
> diff --git a/lib/lyx2lyx/LyX.py b/lib/lyx2lyx/LyX.py
> index 66108dc..1e2147d 100644
> --- a/lib/lyx2lyx/LyX.py
> +++ b/lib/lyx2lyx/LyX.py
> @@ -85,7 +85,7 @@ format_relation = [("0_06",[200], minor_versions("0.6" 
> , 4)),
> ("1_5", list(range(246,277)), minor_versions("1.5" , 7)),
> ("1_6", list(range(277,346)), minor_versions("1.6" , 10)),
> ("2_0", list(range(346,414)), minor_versions("2.0" , 8)),
> -   ("2_1", list(range(414,475)), minor_versions("2.1" , 0)),
> +   ("2_1", list(range(414,475)), minor_versions("2.1" , 5)),
> ("2_2", list(range(475,509)), minor_versions("2.2" , 0))
>
> Scott




-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: 2.2beta sometimes saves documents like *-347.lyx

[Liviu Andronic]

On Sun, Mar 27, 2016 at 2:22 PM, Jean-Marc Lasgouttes
 wrote:
> Then we use the LyX format. But this is for a minority of users.
>
Indeed, makes sense.

Liviu


> Jmarc
>
> Le 27 mars 2016 12:03:37 GMT+02:00, Liviu Andronic  a 
> écrit :
>>On Sun, Mar 27, 2016 at 9:15 AM, Jean-Marc Lasgouttes
>> wrote:
>>> We could have a dialog with a "don't show me again thing. And maybe a
>>way to disable the feature.
>>>
>>> Do we have a way to obtain the real world version number (2.1). This
>>would be easier to understand than 437.
>>>
>>But what happens when people go from 2.0GIT to 2.0 final?
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: 2.2beta sometimes saves documents like *-347.lyx

[Liviu Andronic]

On Sun, Mar 27, 2016 at 9:15 AM, Jean-Marc Lasgouttes
 wrote:
> We could have a dialog with a "don't show me again thing. And maybe a way to 
> disable the feature.
>
> Do we have a way to obtain the real world version number (2.1). This would be 
> easier to understand than 437.
>
But what happens when people go from 2.0GIT to 2.0 final?

Either way, I agree that a pop-up dialog could be more confusing than
useful, and that a naming scheme including "format" or "lyxformat"
would alleviate confusion in most instances. So:
filename-format-412.lyx or filename-lyxformat-412.lyx

Regards,
Liviu


> Jmarc
>
> Le 27 mars 2016 07:52:50 GMT+02:00, Scott Kostyshak  a 
> écrit :
>>> We don't want to get too verbose, ;-) It doesn't matter that much,
>>but I
>>> thought "format" was more indicative or what the file really is.
>>Maybe
>>> "lyxformat"?
>>
>>I'm fine with any of your suggestions. Maybe someone else has a strong
>>opinion?
>>
>>Scott
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: 2.2beta sometimes saves documents like *-347.lyx

[Liviu Andronic]

On Tue, Mar 22, 2016 at 10:59 PM, Scott Kostyshak  wrote:
> On Tue, Mar 22, 2016 at 09:46:14PM +0100, Liviu Andronic wrote:
>> Dear all,
>> With the pre-releases I sometimes (very rarely) notice a strange
>> behavior, whereas LyX saves a document like: filename-412.lyx
>>
>> The numbers are always random, three digits. The strangely-named files
>> appear in the same dir as the original filename.lyx file. I never know
>> how to replicate this, nor if it's an issue (e.g. some stray backup
>> being created by LyX).
>>
>> Has anyone else noticed something like this?
>
> Yes, this happens when you open and save a file that had a previous file
> format. This way, if lyx2lyx causes data loss and you save your file,
> you can still recover the original file.
>
> It is a new feature in 2.2.0.
>
Oh, nice feature. Perhaps we should display a quick pop-up telling the
user this happened? I mean, this probably happens rarely enough, and
otherwise the user may end up none the wiser (like I did) finding a
strangely-named file in the working directory.

Also, do we mention this in About > Release notes? I couldn't spot any
reference to this...

Regards,
Liviu


> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

2.2beta sometimes saves documents like *-347.lyx

[Liviu Andronic]

Dear all,
With the pre-releases I sometimes (very rarely) notice a strange
behavior, whereas LyX saves a document like: filename-412.lyx

The numbers are always random, three digits. The strangely-named files
appear in the same dir as the original filename.lyx file. I never know
how to replicate this, nor if it's an issue (e.g. some stray backup
being created by LyX).

Has anyone else noticed something like this?

Regards,
Liviu


-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: inconsistent labeling of collapsed branch insets

[Liviu Andronic]

Dear all,
A couple of months back we discussed briefly some labelling and
display issues with collapsed branches, which often makes them very
hard to visually distinguish from one another. There seemed to be some
consensus for the proposal below:


On Mon, Aug 31, 2015 at 12:18 PM, Jean-Marc Lasgouttes
 wrote:
> Le 31/08/2015 10:49, Liviu Andronic a écrit :
>>>
>>> Wouldn't proper color instead of 'Branch:' work better? P
>>>
>> For me branches are already very clearly, visually distinguishable by
>> way of cross/checkbox icon preceding any branch inset; I don't know
>> any other inset doing this. Adding color would only help things.
>> Either way, 'Branch:' string is redundant IMO for collapsed branches.
>>
>> My proposal would be to:
>> - keep cross/checkbox icon
>> - (optionally) use color specific to branches
>> - include branch name ("someBranch") in inset label at all times,
>> whether collapsed or not
>> - followed up by any summary of the branch contents as we are doing now
>> - (optionally) for uncollapsed branches, keep 'Branch:' string as we
>> are doing now
>>
>> This will keep collapsed branches short, easily distinguishable from
>> other insets, and easily distinguishable among different branches.
>
>
> I agree with that. Note that color coding is never enough since some people
> have color-blindness issues.
>
And I would propose an even simpler solution:
- do away with the summary of the branch contents in all cases.

It's necessarily (too) short, doesn't always convey any useful info
about the contents of the branch (e.g. can be "..."), we don't do this
for other insets (e.g. Notes), a (longer) summary is always available
when hovering the collapsed branch, it can be woefully inconsistent in
practice. For an example of how things can look bad see attached LyX
file.

- when a branch is collapsed, always use this scheme to identify it:
cross/checksign followed by "Branch: someBranch" string; same as when
the branch is uncollapsed.

This provides a very consistent UI arrangement. And most of the times
the collapsed branches aren't excessively long. They tend to get
longer in master/child setups, but even so I believe branches tend to
be used in at least paragraph-long contexts, meaning that most of the
times such insets are alone on their own paragraph (some label length
isn't a big concern).


I have a document with a dozen branches, many of them collapsed...
Needless to say visually it's a mess. A more consistent display of
labels would be an improvement UI-wise.

Scott, any chance this could still make it into the next beta if there
is some consensus? This is definitely nothing critical, though.

Regards,
Liviu


> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library


lyx-branch-collapse-issues.lyx
Description: Binary data

Re: microtype

[Liviu Andronic]

On Fri, Feb 19, 2016 at 1:06 AM, Pavel Sanda  wrote:
> LaTeX experts,
>
> is there some obstacle I should be aware of before implementing microtype
> support via simple checkbox in document setting (plus maybe edit box for
> params) which would result into simple \usepackage[...]{microtype} in header?
> Is there any opposition to add it into lyx? (I dont mean 2.2 obviously.)
>
FWIW I'd like to see this.

Liviu


> Pavel



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Bug in Insert > Special Character > Symbols in beta1 & 2

[Liviu Andronic]

On Wed, Feb 17, 2016 at 11:33 PM, Andrew Parsloe  wrote:
>
>
> On 17/02/2016 6:12 p.m., Scott Kostyshak wrote:
>>
>> On Tue, Feb 16, 2016 at 10:11:54AM +0100, Liviu Andronic wrote:
>>>
>>> On Tue, Feb 16, 2016 at 9:45 AM, Andrew Parsloe 
>>> wrote:
>>>>
>>>> Insert > Special Character > Symbols displays the Basic Latin selection
>>>> of
>>>> symbols on my system. I can choose other selections as expected, but
>>>> choosing the blank line at the head of the list (to display all symbols)
>>>> freezes LyX. This doesn't happen in 2.1.4,  but does in 2.2.0 beta1 and
>>>> beta2 (Uwe's installer of Friday, 12 February 2016) on windows 7.
>>>>
>>> I cannot confirm this with beta1 on Ubuntu - selecting the blank line
>>> in the combobox works fine and doesn't freeze LyX. This may be
>>> platform-specific.
>>
>> Thanks for testing, Andrew. I can't reproduce this either, which is not
>> surprising because I have a similar setup to Liviu.
>>
>> Uwe can you reproduce this?
>>
>> Scott
>
> I've finally discovered where the problem arose. Under Document settings >
> Language I had somehow set the Other button and chosen Unicode (utf8) and
> then under Language package chosen none. Changing both settings to default
> resolves the problem.
>
>  I confess I know essentially nothing about encodings and cannot recall how
> the problem settings arose, let alone how they became document defaults. But
> if those particular values *are* chosen, they do cause a problem. (In my
> ignorance, I have no idea whether someone would consciously choose that pair
> of settings, or whether they are a nonsense pairing.)
>
This I can replicate. However, it's not a permanent freeze. I can see
the CPU spiking, and LyX takes something like 10-15sec to settle, but
then the dialog appears and scrolls fine. I would imagine LyX attempts
to load quite a number of symbols, including hard to render things
like Chinese characters...

Liviu

>
> Andrew
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: State of master and release process

[Liviu Andronic]

On Wed, Feb 17, 2016 at 9:11 PM, Scott Kostyshak  wrote:
> On Wed, Feb 17, 2016 at 10:31:47AM -0800, Pavel Sanda wrote:
>> Jean-Marc Lasgouttes wrote:
>> >> For the fun of it I dug up a spare Windows machine and tried unpacking
>> >> the beta2 XZ archive using 7-Zip and PeaZip, two open-source file
>> >> archivers for Windows, and ran into the same 100-char truncation
>> >> issue. However, no such issues with Total Commander's internal tar
>> >> unpacker. For instance, I get the full:
>> >>
>> >> lyx-2.2.0beta2\3rdparty\boost\boost\numeric\conversion\detail\preprocessed\numeric_cast_traits_long_long.hpp
>> >>
>> >> Uwe, could you try Total Commander? It comes with an easy to use GUI.
>> >
>> > I am not sure it is worth experimenting since we have now switch from
>> > tar-pax to the more widely available ustar format. It is this new tarball
>> > that should be considered.
>>
>> Scott, can you post the new tarball for Liviu to test? Pavel
>
> tars from current master are there:
> https://www.dropbox.com/sh/7mwmbplao6cs9jq/AAARRH4kzMKacA3k0hh_goQea?dl=0
>

The XZ archive seems to work fine with 7-zip.  No truncated file names
that I can see.
Liviu

> I did not post publicly the one I sent to Uwe because it was marked as
> beta3 and I did not want that out there in the case we did not go with
> beta3 (which we did not).
>
> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: State of master and release process

[Liviu Andronic]

On Tue, Feb 16, 2016 at 8:06 PM, Georg Baum
 wrote:
>> is possible to compile on Windows from the self-contained archive. There
>> is a problem with extracting the tar on Windows, so I have just sent Uwe
>> a zip file containing the same files that the tar contains.
>
> I would formulate it differently: There is a problem  with extracting the
> tar with the tool Uwe used. There are many utilities that support tar, and I
> know that at least one (GNU tar on cygwin or from GnuWin32) can extract the
> archive correctly. Maybe others understand it as well.
>
For the fun of it I dug up a spare Windows machine and tried unpacking
the beta2 XZ archive using 7-Zip and PeaZip, two open-source file
archivers for Windows, and ran into the same 100-char truncation
issue. However, no such issues with Total Commander's internal tar
unpacker. For instance, I get the full:
 
lyx-2.2.0beta2\3rdparty\boost\boost\numeric\conversion\detail\preprocessed\numeric_cast_traits_long_long.hpp

Uwe, could you try Total Commander? It comes with an easy to use GUI.

Regards,
Liviu


>> If the zip file extracts correctly and Uwe can compile for Windows, does
>> this mean that we should release beta2 as long as we post the zip file
>> and in the email announcement we recommend the zip file if compiling on
>> Windows?
>
> I'd do that.
>
>> Or because the tar has issues with being extracted on Windows,
>> we must move to beta3 which hopefully (still not confirmed) would
>> produce a tar that can be extracted correctly with the Windows build? A
>> separate question is does it matter that the 'make lyxdist' command for
>> beta2 did not produce the zip file that would be posted as beta2?
>
> IMHO it does not matter. The important thing is that the files contained in
> the zip and the tar are identical. How this is checked (manually or by
> creating both with a Makefile rule) is not important. Also, I would consider
> the tag in git the authorative source. I does not say anything about tar
> packages. I think it is the jopb of the releases manager to ensure that the
> published source archives are identical with the tagged git source.
>
>> It seems to me that although it is indicative of an inexperienced
>> release manager, the best thing would be to move to beta3, and confirm
>> with Uwe before posting the files that the archive can be extracted and
>> that the Windows build succeeds. I don't have a strong opinion on this
>> though.
>
> I don't think it is needed. Using the better format for the next release (I
> hope there will not be a beta 3) is good, but not required for beta2.
>
>
> Georg
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Bug in Insert > Special Character > Symbols in beta1 & 2

[Liviu Andronic]

On Tue, Feb 16, 2016 at 9:45 AM, Andrew Parsloe  wrote:
> Insert > Special Character > Symbols displays the Basic Latin selection of
> symbols on my system. I can choose other selections as expected, but
> choosing the blank line at the head of the list (to display all symbols)
> freezes LyX. This doesn't happen in 2.1.4,  but does in 2.2.0 beta1 and
> beta2 (Uwe's installer of Friday, 12 February 2016) on windows 7.
>
I cannot confirm this with beta1 on Ubuntu - selecting the blank line
in the combobox works fine and doesn't freeze LyX. This may be
platform-specific.

Liviu


> Andrew
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: beta2?

[Liviu Andronic]

On Sat, Feb 13, 2016 at 6:01 PM, Scott Kostyshak  wrote:
> On Sat, Feb 13, 2016 at 12:34:26PM +0100, Peter Kümmel wrote:
>> Am 13.02.2016 um 10:57 schrieb Georg Baum:
>> >Scott Kostyshak wrote:
>> >
>> >>I agree that it would be nice to remove unnecessary files. As far as
>> >>figuring out which files are unnecessary, I volunteer to take any
>> >>experimental patch, build a tar ball, and send it to Uwe to see if he
>> >>has time to build the test tar ball so we can see if he gets an error.
>> >
>> >The files are already missing from the beta2 tarball (because they are not
>> >listed in Makefile.am). If Uwe can build from it, we can remove them from
>> >git.
>>
>> No, beta2 does not build on Windows because of missing
>>
>> 3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp
>> 3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp
>>
>> Peter
>
> Thanks for testing, Peter. I'll wait for a fix, and then I suppose we
> move to beta3?
>
We could also do e.g. beta2.1, beta2.2, etc. until the Windows build
issues are sorted out...

Liviu


> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Printer missing in 2.2.0beta1

[Liviu Andronic]

On Sat, Feb 13, 2016 at 6:38 PM, Uwe Stöhr  wrote:
> Am 12.02.2016 um 09:38 schrieb Stephan Witt:
>
>> But this doesn’t solve the problem how to print individual chapters.
>
>
> I don't understand the discussion. You can export to a format you like then
> use the printer dialog of your preferred viewer to print what you like. If
> you only like to print one chapter, then do this. See also LyX's thesis
> template which uses separate LyX files for every chapters.
>
One thing you cannot do from an exported PS or PDF file is print e.g.
LyX Notes. But I'm not sure if this is common practice among users.

Liviu


> regards Uwe



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Printer missing in 2.2.0beta1

[Liviu Andronic]

On Fri, Feb 12, 2016 at 9:58 AM, Stephan Witt  wrote:
> Am 12.02.2016 um 09:46 schrieb Jean-Marc Lasgouttes :
>>
>> Le 12/02/2016 09:38, Stephan Witt a écrit :
>>> But this doesn’t solve the problem how to print individual chapters.
>>
>> What do you mean?
>
> The export filter to send the document to printer prints the whole thing, 
> right?
>
I suspect that you can always set your printer command to print to
file (PS or PDF), and then print from there the pages you're
interested in. Perhaps we should document a number of printing
converters that people might find useful (i.e. propose exact syntax),
to replace this no longer available functionality.

Liviu


> Stephan



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Printer missing in 2.2.0beta1

[Liviu Andronic]

On Fri, Feb 12, 2016 at 9:55 AM, Buenas Noticias  wrote:
> Yes. The Ctrl+P binding, is the solution at this problem.
>
The old functionality was removed. A potential new Ctrl+P binding
would probably be bound to a PDF format preview or some other format
that is deemed a suitable default. No decision on that has been made
yet.

Liviu


> Miguel
>
>
> El 12/02/16 a las 09:46, Jean-Marc Lasgouttes escribió:
>
>> Le 12/02/2016 09:38, Stephan Witt a écrit :
>>>
>>> But this doesn’t solve the problem how to print individual chapters.
>>
>>
>> What do you mean?
>>
>> BTW Richard, what happened with the idea of reusing the Ctrl+P binding
>> for some printing-like activity?
>>
>> JMarc
>>
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Printer missing in 2.2.0beta1

[Liviu Andronic]

On Fri, Feb 12, 2016 at 10:01 AM, Jean-Marc Lasgouttes
 wrote:
> Le 12/02/2016 09:58, Stephan Witt a écrit :
>>
>> Am 12.02.2016 um 09:46 schrieb Jean-Marc Lasgouttes :
>>>
>>>
>>> Le 12/02/2016 09:38, Stephan Witt a écrit :

 But this doesn’t solve the problem how to print individual chapters.
>>>
>>>
>>> What do you mean?
>>
>>
>> The export filter to send the document to printer prints the whole thing,
>> right?
>
>
> Right. Another approach is to create a format that goes to PDF and view
> this. From there, one can print whatever pages.
>
I suspect some used this functionality to print drafts, including notes, etc.

Liviu


> JMarc



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Printer missing in 2.2.0beta1

[Liviu Andronic]

On Fri, Feb 12, 2016 at 7:59 AM, Buenas Noticias  wrote:
> Hi all:
>
> I use in command line psbook, psnup, psselect to print books or pamphlets
> and need the printer when printing individual chapters or sections. This I
> can make in 2.1.4, but no in 2.2.0beta1. How I can get these?
>
Yes, support for printing has been removed. See Help > About > Release Notes:
"Support for printing from within LyX (File> Print) has been removed.
LyX's printing support was very limited, and most users will want to
print after reviewing an output document (e.g., a PDF), anyway, which
can be done from the PDF viewer. Users who would like to restore this
functionality can create a "printer" format from within LyX and then
define, say, a pdf->printer converter that does nothing but call lpd,
or a2ps, or whatever. The "printer" will then be available as an
export option. "


Liviu


> Thanks advanced
>
> Miguel



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: 2.2.0beta1 tar balls are available

[Liviu Andronic]

On Wed, Feb 10, 2016 at 4:18 AM, Scott Kostyshak  wrote:
> The tar balls and sig files are here:
>
> https://www.dropbox.com/sh/y57gkjh8xo89ct4/AACbDGN83b4eq0cjkgR8tsq9a?dl=0
>
> Packagers, please prepare your binaries.
>
For Ubuntu:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily


Liviu



> Non-packagers, please do a quick test of compilation (from the tar ball) and
> basic functionality on your platform, and let us know how it goes.
>
> Thank you all for your help,
>
> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Fwd: [Build #8773158] i386 build of lyx2.2 2.2.0~git20151230~ubuntu12.04.1 in ubuntu precise RELEASE [~lyx-devel/ubuntu/daily]

[Liviu Andronic]

On Sun, Jan 3, 2016 at 9:21 AM, Scott Kostyshak  wrote:
> On Sat, Jan 02, 2016 at 04:42:35PM +0100, Liviu Andronic wrote:
>> On Thu, Dec 31, 2015 at 8:56 PM, Scott Kostyshak  wrote:
>> > On Wed, Dec 30, 2015 at 08:09:15PM +0100, Liviu Andronic wrote:
>> >> Dear all,
>> >> This past week I've been getting daily build failures of LyX on Ubuntu
>> >> Precise (see build log link below). The configure process finishes
>> >> like this:
>> >> configure: creating ./config.status
>> >> config.status: error: cannot find input file: `Makefile.in'
>> >> make[1]: *** [override_dh_auto_configure] Error 1
>> >> make[1]: Leaving directory `/«PKGBUILDDIR»'
>> >> make: *** [build] Error 2
>> >> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>> >>
>> >>
>> >> Is there something that might have changed in a recent commit to
>> >> generate such an error? Strangely, none of the other Ubuntu distros
>> >> seems to be affected.
>> >>
>> >> Regards,
>> >> Liviu
>> >
>> > We just had a thread a couple of days ago that we CC'ed you on. JMarc
>> > posted a patch. Did you receive the emails? Maybe you wrote this email
>> > before and it was just sent now.
>> >
>> Thanks Scott. I can confirm that JMarc's commit fixes things, and now
>> daily builds on Precise no longer fail.
>
> Thanks for the confirmation. It will be interesting to see how long we
> can keep 12.04 alive. It is good to know that once 16.04 is released LyX
> can be easily built on three LTS releases. That's pretty good.
>
Precise is supported by Canonical until 2017, and Precise ships Qt
4.8.1. As long as we keep minimum requirements to <= 4.8.x, probably
not before subsequent major release, we'll probably keep supporting
this LTS release. Canonical will likely stop supporting Precise
(including Launchpad builds) well before LyX becomes incompatible with
Precise.

Liviu


> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Fwd: [Build #8773158] i386 build of lyx2.2 2.2.0~git20151230~ubuntu12.04.1 in ubuntu precise RELEASE [~lyx-devel/ubuntu/daily]

[Liviu Andronic]

On Thu, Dec 31, 2015 at 8:56 PM, Scott Kostyshak  wrote:
> On Wed, Dec 30, 2015 at 08:09:15PM +0100, Liviu Andronic wrote:
>> Dear all,
>> This past week I've been getting daily build failures of LyX on Ubuntu
>> Precise (see build log link below). The configure process finishes
>> like this:
>> configure: creating ./config.status
>> config.status: error: cannot find input file: `Makefile.in'
>> make[1]: *** [override_dh_auto_configure] Error 1
>> make[1]: Leaving directory `/«PKGBUILDDIR»'
>> make: *** [build] Error 2
>> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>>
>>
>> Is there something that might have changed in a recent commit to
>> generate such an error? Strangely, none of the other Ubuntu distros
>> seems to be affected.
>>
>> Regards,
>> Liviu
>
> We just had a thread a couple of days ago that we CC'ed you on. JMarc
> posted a patch. Did you receive the emails? Maybe you wrote this email
> before and it was just sent now.
>
Thanks Scott. I can confirm that JMarc's commit fixes things, and now
daily builds on Precise no longer fail.

Cheers,
Liviu


> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Fwd: [Build #8773158] i386 build of lyx2.2 2.2.0~git20151230~ubuntu12.04.1 in ubuntu precise RELEASE [~lyx-devel/ubuntu/daily]

[Liviu Andronic]

Dear all,
This past week I've been getting daily build failures of LyX on Ubuntu
Precise (see build log link below). The configure process finishes
like this:
configure: creating ./config.status
config.status: error: cannot find input file: `Makefile.in'
make[1]: *** [override_dh_auto_configure] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


Is there something that might have changed in a recent commit to
generate such an error? Strangely, none of the other Ubuntu distros
seems to be affected.

Regards,
Liviu


-- Forwarded message --
From: Launchpad Buildd System 
Date: Wed, Dec 30, 2015 at 3:06 PM
Subject: [Build #8773158] i386 build of lyx2.2
2.2.0~git20151230~ubuntu12.04.1 in ubuntu precise RELEASE
[~lyx-devel/ubuntu/daily]
To: Liviu Andronic 



 * Source Package: lyx2.2
 * Version: 2.2.0~git20151230~ubuntu12.04.1
 * Architecture: i386
 * Archive: ~lyx-devel/ubuntu/daily
 * Component: main
 * State: Failed to build
 * Duration: 2 minutes
 * Build Log: 
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily/+build/8773158/+files/buildlog_ubuntu-precise-i386.lyx2.2_2.2.0%7Egit20151230%7Eubuntu12.04.1_BUILDING.txt.gz
 * Builder: https://launchpad.net/builders/lcy01-35
 * Source: not available



If you want further information about this situation, feel free to
contact a member of the Launchpad Buildd Administrators team.

--
i386 build of lyx2.2 2.2.0~git20151230~ubuntu12.04.1 in ubuntu precise RELEASE
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily/+build/8773158

You are receiving this email because your team LyX Team is the owner of
this archive.


-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: A margin-al question

[Liviu Andronic]

On Fri, Dec 11, 2015 at 3:08 PM, Jean-Marc Lasgouttes
 wrote:
> Does this mean that the "limit text width" feature of full text handling
> should apply to normal mode too? That would be trivial.
>
Yes, this is precisely what I hope that bug #9376 would fix. Either
the same checkbox (suitably renamed), or a different checkbox along
the lines of "limit text width in non-fullscreen mode".

Regards,
Liviu


> Note that when one opens a panel, the text moves anyway, which is not really
> comfortable. In this case detaching the panels is probably the best bet
> (mac-like opration).
>
>> Personally I would love to be able to set margins and the line spacing
>> as I see it fit like I can do on my kindle
>>
>> (),
>> possibly with a maximum line width.
>
>
> Yes it is sexy, but it is only useful once or twice. Or are you constantly
> changing sizes?
>
> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: alpha2 uploaded and ready for packaging

[Liviu Andronic]

On Fri, Nov 27, 2015 at 9:57 AM, Scott Kostyshak  wrote:
> alpha2 tarballs can be found here:
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha2/
>
Ubuntu packages are now on the PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

Liviu


> I will announce it once Windows and Mac installers are available.
>
> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Packagers, please upload binaries for 2.2.0alpha1

[Liviu Andronic]

On Fri, Nov 20, 2015 at 12:23 AM, Richard Heck  wrote:
> On 11/19/2015 06:15 PM, Uwe Stöhr wrote:
>> Am 19.11.2015 um 01:12 schrieb Scott Kostyshak:
>>
>>> The benefit of signing files is so that whoever downloads the file can
>>> be confident that it is the same file that you uploaded. Downloads and
>>> uploads are not often corrupted as they were before, but a file is made
>>> up of many 0's and 1's which are sent through wires.
>>
>> Thanks for the explanation. I understand that a download can go wrong
>> but It is not clear to me what would happen that could harm anybody.
>> if a download is broken you will most probably not be able to install
>> LyX with this installer and we will get quickly complaints by users.
>> What else could happen?
>
> The worry is not that the download goes wrong, but that someone manages
> somehow to put a virus into your installer. This could happen in a
> number of different ways, for example, via a man-in-the-middle attack.
> Or someone could hack into your Sourceforge account and replace the
> file. It's happened.
>
This. Also providing a checksum is a *very* low effort requirement,
and it will take very little time to compute the hash of a given file
using your favorite checksum utility, like Hashtab on Windows and Mac
OS X or GtkHash on Linux. This is easier done than said.

PGP signatures on the other hand are a bit more work to understand
conceptually and set up in practice, although as Scott mentions it's a
5 min job with proper guidance. The cryptographic signature is a step
above simple checksums in ascertaining both the origin and integrity
of the file: *you* are the only one holding the private key, and a
file signed by you can be verified by *anyone* using your public key.

Cheers,
Liviu


> If you send Scott and MD5 sum (and me, actually), then we can be
> confident that the file has not been altered. So our signature means
> something.
>



> Richard
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Packagers, please upload binaries for 2.2.0alpha1

[Liviu Andronic]

On Mon, Nov 16, 2015 at 11:23 PM, Scott Kostyshak  wrote:
> Thanks for uploading to the PPA. I made a few changes to the
> description:
>
> "upcoming 2.1 release" -> "upcoming 2.2 release"
> and I added a new legend item:
> lyx2.2pre -- a pre-release (e.g. alpha, beta) of an upcoming
> (development) major release
>
Thanks, Scott. Looks good.

Liviu


-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Packagers, please upload binaries for 2.2.0alpha1

[Liviu Andronic]

On Mon, Nov 16, 2015 at 12:46 PM, Guillaume Munch  wrote:
> Le 16/11/2015 11:33, Liviu Andronic a écrit :
>>
>> The Ubuntu packages are built against Qt 4.8. Scott, is it a good or a
>> bad idea to build against Qt 5.4.1/5.4.2, where available?
>>
>
> With Qt 5.4.1 in Ubuntu I am affected by
> <http://www.lyx.org/trac/ticket/9218> and
> <http://www.lyx.org/trac/ticket/9731>. On the other hand,
> <http://www.lyx.org/trac/ticket/9362> is solved with Qt 5.4.1. But the
> latter has workarounds.
>
So overall not a very good idea. Thanks,
Liviu


>
> Guillaume
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Packagers, please upload binaries for 2.2.0alpha1

[Liviu Andronic]

On Sat, Nov 14, 2015 at 8:34 PM, Scott Kostyshak  wrote:
> The tar balls are here:
>
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/
>
I've uploaded Ubuntu packages to the development PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily

Testers should install the lyx2.2pre package, and this installation is
independent of the stable LyX installation that you might have.


> I would like to make the announcement for the alpha release on Monday.
> From what I understand in the past it is OK if the announcement comes
> before binaries are uploaded (please let me know if I am incorrect).
>
> As for which version of Qt to use, I propose that each packager decides
> what is the best choice for the platform. Qt 5.6 Beta has been delayed
> again until 19th November 2015. I did not bother looking at the reason
> this time.
>
The Ubuntu packages are built against Qt 4.8. Scott, is it a good or a
bad idea to build against Qt 5.4.1/5.4.2, where available?

Liviu


> Thanks,
>
> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Tentative schedule for 2.2.0 release

[Liviu Andronic]

On Thu, Nov 12, 2015 at 1:45 AM, Pavel Sanda  wrote:
> Liviu Andronic wrote:
>> no major crashes. Unless we have major issues that need addressed and
>> fixed prior to this major release, I think the general hope around is
>> that we get an RC and even the actual release by the end of the year,
>> or perhaps very early next year.
>
> I do not think that 1.5 months provide enough time frame even to discover
> problematic bugs.
>
Yeah, my memories were (very) optimistic concerning past releases...
Should have checked first.

Liviu


> I agree with JMarc that we could be flexible WRT shortcuting the dates in case
> things look good, but I also know that all plans we ever had for our
> releases were delayed. Let's see :)
>
> Pavel



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Tentative schedule for 2.2.0 release

[Liviu Andronic]

On Wed, Nov 11, 2015 at 7:10 PM, Scott Kostyshak  wrote:
> On Wed, Nov 11, 2015 at 01:20:35PM +0100, Jean-Marc Lasgouttes wrote:
>> Le 11/11/2015 09:02, Scott Kostyshak a écrit :
>> >Below is a tentative schedule for releasing 2.2.0. I think the schedule
>> >is slightly on the aggressive side, and that is because I think the
>> >state of our master branch is already relatively stable.
>> >
>> >alpha: tag and tar this week and announce this weekend or Monday
>> >beta: beginning of January
>> >RC: end of March
>> >final: end of April
>>
>> I would have hoped for a more aggressive schedule, I just hope that we are
>> not bound by it. If this lasts too long, there will be a lot of frustration
>> and pressure for adding more features. So trying to be fast also has value.
>
> What stage(s) would you propose making shorter?
>
I think in the past, without major deal-breaking bugs, the jumps from
one pre-release to another took fewer than 2-3 weeks. And that's when
we were dealing with obscure crashes... Now master is (very) stable,
no major crashes. Unless we have major issues that need addressed and
fixed prior to this major release, I think the general hope around is
that we get an RC and even the actual release by the end of the year,
or perhaps very early next year.

Liviu


> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: status update on the export tests

[Liviu Andronic]

On Mon, Oct 26, 2015 at 10:24 AM, Guenter Milde  wrote:
> On 2015-10-26, Scott Kostyshak wrote:
>
>> OK. I just want to make sure we define "there are no regressions". These
>> tests passed before edd37de8. So it is quite possible that documents
>> that users have that compile with LyX 2.1.x suddenly fail to compile
>> with LyX 2.2.0 because of edd37de8. In this sense, there is a
>> regression.
>
>> So there is a trade-off: the bad side is that there is the possibility
>> that user's documents suddenly fail to compile. The good side is that we
>> now encourage the use of polyglossia by default which apparently has
>> advantages over babel. Jürgen knowingly made this decision and he knows
>> more than I do to be able to judge this tradeoff so I hesitantly accept
>> it.
>
> Polyglossia has been the better (and sometimes only) choice for use with
> Xe/LuaTeX Unicode fonts for a long time, but Babel is catching up in the
> last years.
>
> It may be that we need a new keyword for lib/languages, to tag
> languages where Babel is superior to Polyglossia also with non-TeX fonts.
>
> Then, the "automatic" setting (which is also the default "default") could
> take into account that some languages should use Babel also with non-TeX
> fonts even if Polyglossia is available for them.
>


> Could this prevent some of the regressions? (We need to look carefully, not
> only if the relevant documents compile without error, but also if the
> exported document is OK.)
>
By exported document do you mean .tex or .pdf? If it is .tex, would it
be a good idea to check whether the latest export is identical to a
reference .tex generated when creating the test; if not, display a
diff. Simply relying on the exit code seems like an easy way to miss
non-error generating regressions...

Liviu


> Günter
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Build bot reactivated

[Liviu Andronic]

On Fri, Oct 23, 2015 at 9:07 PM, Richard Heck  wrote:
> On 10/23/2015 12:52 PM, Peter Kümmel wrote:
>>
>> I've reactivated the build-bot for Windows binaries of the master branch.
>> It uses GCC 4.8.2 and Qt 5.5.1 (32 bit).
>>
>> http://syntheticpp.github.io/LyX-bleeding-edge
>>
>> Maybe it helps a bit for 2.2.
>
>
> You should add a warning that using those binaries could melt you monitor
> and has also been found to cause cancer in laboratory rats. ;-)
>
Last I heard, before the previous major release LyX was a child eating
monster... :)

Liviu


> Richard
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Form is function

[Liviu Andronic]

On Tue, Oct 20, 2015 at 8:52 PM, Scott Kostyshak  wrote:
> On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote:
>> Scott asked not long ago what could be done to make it easier for
>> newcomers. It is now clear to me that having a clearer bug tracker
>> is an aspect that can be improved. In addition, the initial question
>> was to know what to do with tickets with an unmet milestone.
>>
>>
>> Taking into account what has been said, here are three proposition:
>>
>>
>> 1. Milestones remain the main recipient of triaging information
>>   + Unmet milestones are reverted to ".x", which are given more
>> visibility.
>>   + Severity is the secondary information used to order the lists.
>>   + Color is supposed to distinguish enhancements from defects, though
>> it is not really observed currently (indeed this colour code was
>> kept secret!).
>>   - As I see it, it leads to an information which is fragmented between
>> three different milestones, which is maybe why it did not work in
>> the past.
>>
>>
>> or:
>>
>>
>> 2. Priority (colour) becomes the main recipient of the triaging
>>information.
>>+ A list of all "important" defects regardless of milestone is
>>  given visbility in addition to what we have already.
>>+ "Important" enhancement are shown as well in a list separate from
>>  the previous one; the colour do not means the same for
>>  enhancements and defects.
>>+ An unmet milestone can be removed safely: bump the priority if
>>  necessary.
>>- While colouring is attractive, it is against pre-existing
>>  conventions. The colour code should be similar for defects
>>  (yellow/red) but would differ for enhancements (essentially all
>>  light blue enhancements would become untriaged).
>>- Also, severity was already used to rate tickets on a scale.
>>
>>
>> or a new proposition:
>>
>>
>> 3. Severity becomes the main recipient of the triaging information.
>>   + A list of all important defects regardless of milestone
>> (major/critical/blocker) is given the visibility.
>>   + A list of all consensual enhancements regardless of milestone is
>> found at the end of the front page (e.g. major/critical).
>>   + An unmet milestone can be removed safely; bump the severity if
>> necessary.
>>   + Does not invalidate the color convention which we can explain
>> separately, and is consistent with the previous use of severity.
>
> From what I understand there has been no preference expressed by anyone
> besides Guillaume on this. Does anyone else prefer one of the three
> options (or a different one)? Liviu since you have been involved earlier
> in the discussion, can you summarize your opinion with respect to the
> propositions Guillaume outlined (or a new proposition) ?
>

I think #1 is more or less what we have now, slightly simplifying the
way we roll milestones (into the .x stack) or drop milestones
altogether ("very" old .x reports can be safely decommissioned).
#2 will allow to much better keep track of "important" tickets, across
major releases, but it will also require some change in bugtracker
habits as well as more or less constant supervision (at least at
first). It will require from devels a conscious triaging effort to
assess importance, but it will allow to not forget important issues or
missing features even when they're very old.
#3 seems to be like the above while keeping our current color
conventions on bugtracker.

In truth, I have only but a small voice in this. Best would be for our
release managers and active developers to signal which scheme they
would be most comfortable with. And as Pavel has already mentioned,
the crucial part for either of Guillaume's proposals---since they
involve more departure from what we are currently doing---would be for
him to become actively involved in the triaging efforts on Bugtracker
for "some" time, so that the new habits stick with the old-timers;
otherwise devels will probably simply revert to what they've been used
to before.

If Guillaume does assume this role, I think either of the proposed
schemes could work just nicely, and maybe we really do need a more
sensible and nuanced way to prioritize the importance of incoming
reports and keep track of them across major releases (as long as it is
indeed the devel team that decides on the priorities, not the
reporters)... And since Guillaume is clearly motivated, I think a
change in bugtracker practices could ultimately prove a positive a
change for the team in terms of moving the project forward.

Regards,
Liviu


> Guillaume (and others), I would like to go through the bugs with
> milestone 2.2 soon. My only goal will be to figure out which tickets
> should keep 2.2 as a milestone and which should not. I'll make some
> decisions about moving some tickets to 2.3 or 2.2.x but I do not plan on
> thinking carefully about the severity or importance. I will assume that
> anyone who cares about the particular ticket wi

Re: We don't want google to index trac tickets?

[Liviu Andronic]

On Sat, Oct 17, 2015 at 12:52 AM, Scott Kostyshak  wrote:
> I was trying to view a trac ticket and because our server is down I
> wanted to find it on google and view the cache.
>
If it can be of any consolation, Xfce does the same thing:
http://xfce.10915.n7.nabble.com/https-bugzilla-xfce-org-robots-txt-td45275.html#a45285

https://bugzilla.xfce.org/show_bug.cgi?id=11404

Apparently it's an issue of server capacity given that search engines
tend to send a lot of requests. Given our somewhat frequent server
downtimes, it's probably wise to keep robots off the site. Some
suggest however that the rate of search engine overload can be
controlled (see above links).

Liviu



> I entered the following into google:
> site:http://www.lyx.org/trac/ticket/
>
> This results in many entries that say:
> A description for this result is not available because of this site's
> robots.txt
>
> It would be nice to have our trac tickets indexed by Google because
> often users type a problem they are having into google.
>
> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Form is function

[Liviu Andronic]

On Wed, Oct 14, 2015 at 7:55 AM, Guillaume Munch  wrote:
>> the hard truth is that our manpower is limited and our devels barely
>>  have the bandwidth to address crashes, regressions and the like (in
>>  between monitoring tickets, triaging, helping on the MLs, and
>> implementing things sorely needed to keep up with software
>> developments or just implementing things they need themselves). All
>> those red color-coded tickets on Trac tend to focus spirits and keep
>>  devels around the bugs that absolutely need to get fixed until the
>> next release.
>
>
> I already did all of what you describe in addition to implementing
> long-standing feature requests and last-minute fixes of compilation;
> I am not going to take an authoritative argument about what I need.
>
This was never meant as a rebuke or criticism to any one devel in
particular (or to the team, for the matter), but merely what seems
like a factual description of how our devels operate and their
constraints.

Cheers,
Liviu

Re: Form is function

[Liviu Andronic]

On Tue, Oct 13, 2015 at 2:46 AM, Guillaume Munch  wrote:
> Le 13/10/2015 00:53, Scott Kostyshak a écrit :
>>
>> On Sun, Oct 11, 2015 at 10:28:23PM +0200, Liviu Andronic wrote:
>>>
>>> On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch  wrote:
>>> The problem with letting community members define what is important
>>> and what is not, is that for each and every one of us our pet bug is
>>> the most importantest of 'em all. Until now we had a somewhat rigid
>>> system of determining what is of high importance (i.e. crash) and what
>>> is not (i.e. enhancement), and this seems to work quite well for our
>>> core devels.
>>
>>
>> Thank you for all of the discussion on this topic. My priority will be
>> changing tickets that have the 2.2.0 miletone to either remove the
>> milestone or change it to 2.2.x or 2.2.1. Please feel free to change the
>> priority or severity and of course to disagree with a decision I make
>> regarding the milestone and anything else.
>>
>
>
> My point again: whatever field we use to denote the triaging information,
> the tracker should be set up to direct users towards this usage. I would
>
At the end of the day Trac is there to assist devels, not users. While
"it has always been like this" is never a good reason to keep
something as it is, if some convention works reasonably well then we
should not try to fix what's not broken. The current system seems to
work well enough for most devels, and allows to keep things useful. I
did my best to try to explain some of the rationale behind what we
have, and why it may be something that works well enough and requires
only some minor tweaks. Maybe we just need to document it explicitly
for incoming devels...

While our current system is somewhat rigid, it is also simple and
intuitive for those who actually need and use it. If we go for
something fancier, we may end up distracting our devels from tickets
that actually matter. While I'm personally always very fond of my pet
enhancement requests (and I'd be all for putting 'em all up in red),
the hard truth is that our manpower is limited and our devels barely
have the bandwidth to address crashes, regressions and the like (in
between monitoring tickets, triaging, helping on the MLs, and
implementing things sorely needed to keep up with software
developments or just implementing things they need themselves). All
those red color-coded tickets on Trac tend to focus spirits and keep
devels around the bugs that absolutely need to get fixed until the
next release. (And god knows our releases advance at glacial speeds.)
If we start putting enhancements and other bugs in red, could this end
up in fewer crashes being fixed in a timely manner?

This however is my opinion, and our devels should choose what works
best for them.

Regards,
Liviu


> have been reassured to see people trying to address this side of the issue
> as well. Let us think about this now. First, please, explain to me what the
> milestones ".x" are supposed to mean exactly and I can suggest an
> appropriate change to the tracker page (which may or may not be just "add .x
> milestones to the front page").
>
> In addition, the exchange showed the confusion about the purpose of the
> priority field: Liviu says that it is a "rigid system" to determine what is
> of importance or not, and that we want "priority labels that mean what they
> say", while Pavel reveals that it was just "hijacked" to set up a colour
> code. In any case this code was kept well secret and does not always
> correspond to what I observe in practice on trac.
>
> If you do not like my suggestion to "hijack" the color field again for
> something more intuitive, maybe we can still think about the place we give
> to enhancements, because the current system wrongly gives the impression
> that they are less important (in particular are considered on the same scale
> as defects to begin with). Liviu's objections regarding a long-standing
> "red" enhancement comes in my opinion from a misunderstanding of my proposal
> which I recognise stemming from this way Trac currently makes us think:
> indeed, if enhancements were shown separately from defects (through various
> settings of trac: front page, default columns...), how could a long-standing
> red enhancement diminish the value of red defects? Liviu's example
> ironically shows the need for a way to show that there is a consensus around
> a very desirable feature, however difficult (in a way easier to sort and
> keep up to date than the wiki).
>
> I still think that refocusing the priority field would be more useful than
> .x milestones, in particular because they

Re: [LyX/master] Comply with rule-of-three

[Liviu Andronic]

On Mon, Oct 12, 2015 at 4:17 AM, Scott Kostyshak  wrote:
> On Sun, Oct 11, 2015 at 11:20:15AM +0200, Georg Baum wrote:
>> commit cea2d71e641e6a4023128a367d1cd5a593ed1706
>> Author: Georg Baum 
>> Date:   Sun Oct 11 11:16:09 2015 +0200
>>
>> Comply with rule-of-three
>>
>> The rule-of-three says that if any of virtual destructor, copy 
>> constructor
>> or assignment operator needs to be manually implemented, then all three
>> should be implemented. Otherwise you can get subtle bugs which can be
>> difficult to find. In the changed classes, changing a copy-construction 
>> to
>> an assignment would have had surprising effects. Now they all behave
>> consistently.
>
> Is there any automatic check of the rule-of-three (e.g. by cppcheck or
> Coverity)?
>
I'm not sure, but I don't think so. I did a Coverity check today, and
there were 14 fixes since last check (about a month ago), most
probably duplicates with cppcheck and fixed courtesy of Georg. I'm
still trying to find my way around Coverity interface, but I think
this is the list:
https://scan4.coverity.com/reports.htm#v12247/p10234/fileInstanceId=4736058&defectInstanceId=1279561&mergedDefectId=111941


I've looked at this particular commit, however, and none of the files
affected here are within the Coverity issues that were fixed. Feel
free to look at them yourself in case I missed something.

Looking at outstanding issues I can see however an unitialized scalar
in src/insets/InsetIPA.cpp (see CID 23447) and
src/insets/InsetPreview.cpp (CID 23426). Both are right above the
changes by Georg.

Liviu




> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: When to court Qt 5.6?

[Liviu Andronic]

On Mon, Oct 12, 2015 at 1:39 PM, Jean-Marc Lasgouttes
 wrote:
> Le 12/10/2015 12:45, Liviu Andronic a écrit :
>>
>> True. :) What is the current minimum Qt 5.x requirement?
>
>
> I do not think that there is any strong requirement. The problem is more in
> Qt5 bugs that this may expose.
>
For what it's worth, it doesn't seem like we officially support Qt 5.x
just yet. From the release notes:
"Changes with respect to external programs and libraries in 2.2:
LyX is not yet supposed to work with Qt5. It is advised to compile and
run LyX against Qt 4.8.x. On Windows Qt 4.8.6 or newer is advised."

Which means that my concerns about Qt 5.6 were a tad premature...


Liviu


> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: When to court Qt 5.6?

[Liviu Andronic]

On Mon, Oct 12, 2015 at 12:43 PM, Jean-Marc Lasgouttes
 wrote:
> Le 12/10/2015 12:38, Liviu Andronic a écrit :
>>
>> So as far as Trusty users are concerned (likely a big chunk of the
>> Ubuntu user base), if 2.2.0 depends on Qt 5.6 they will be locked into
>> Qt 4.8 for the entire 2.2.x series.
>>
>> I don't know if the benefits of depending on Qt 5.6 outweigh such
>> concerns. Maybe if we relied on ifdefs to support in parallel Qt 5.2
>> and 5.6, but I hear this can cause maintenance nightmares...
>
>
> The question is not about requiring qt 5.6 as I understand it. But the fact
> is that it is required for proper HiDPI support and will be used at least
> for the mac binaries.
>
> As far as linux is concerned, we require Qt 4.5, which should be good enough
> :)
>
True. :) What is the current minimum Qt 5.x requirement?

Liviu


> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library