Re: LyX 2.4.0~RC4 does not launch under (GNOME) Wayland

[Cor Blom]

https://bugzilla.opensuse.org/show_bug.cgi?id=1223393

Op 25-04-2024 om 12:49 schreef Saša Janiška:

Hello!

I'm trying to use  LyX-2.4.0-RC$ under openSUSE Tumbleweed running
GNOME Wayland session.

When I launch it under Terminal, is just hangs...if I rm ~/.lyx I get:

$ lyx
LyX: Creating directory /home/gour/.lyx/
LyX: reconfiguring user directory
+Running LyX configure with Python 3.11.9
checking for a Latex2e program...
+checking for "latex"...  yes
checking for pLaTeX, the Japanese LaTeX...
+checking for "platex"...  not in path
checking for a java interpreter...
+checking for "java"...  yes
checking for a perl interpreter...
+checking for "perl"...  yes
checking for xsltproc...
+checking for "xsltproc"...  yes
/bin/sh: line 1: inkscape: command not found
checking for a Tgif viewer and editor...
+checking for "tgif"...  no
checking for a FIG viewer and editor...
+checking for "xfig"...  no
+checking for "jfig3-itext.jar"...  no
+checking for "jfig3.jar"...  no
checking for a Dia viewer and editor...
+checking for "dia"...  no
checking for an OpenDocument drawing viewer and editor...
+checking for "libreoffice"...  yes
+checking for "lodraw"...  yes
+checking for "ooffice"...  yes
+checking for "oodraw"...  yes
+checking for "soffice"...  yes
checking for a Grace viewer and editor...
+checking for "xmgrace"...  no
checking for a FEN viewer and editor...
+checking for "xboard"...  no
checking for a SVG viewer and editor...
+checking for "inkscape"...  no
checking for a raster image viewer...
+checking for "xv"...  no
+checking for "gwenview"...  no
+checking for "kview"...  no
+checking for "eog"...  yes
+checking for "xviewer"...  no
+checking for "ristretto"...  no
+checking for "gpicview"...  no
+checking for "lximage-qt"...  no
+checking for "xdg-open"...  yes
+checking for "gimp-remote"...  no
+checking for "gimp"...  yes
checking for a raster image editor...
+checking for "gimp-remote"...  no
+checking for "gimp"...  yes
checking for a text editor...
+checking for "xemacs"...  no
+checking for "gvim"...  yes
+checking for "kedit"...  no
+checking for "kwrite"...  no
+checking for "kate"...  no
+checking for "nedit"...  no
+checking for "gedit"...  no
+checking for "geany"...  no
+checking for "leafpad"...  no
+checking for "mousepad"...  no
+checking for "xed"...  no
+checking for "notepad"...  no
+checking for "WinEdt"...  no
+checking for "WinShell"...  no
+checking for "PSPad"...  no
checking for a lilypond editor...
+checking for "frescobaldi"...  no
+checking for "xemacs"...  no
+checking for "gvim"...  yes
+checking for "kedit"...  no
+checking for "kwrite"...  no
+checking for "kate"...  no
+checking for "nedit"...  no
+checking for "gedit"...  no
+checking for "geany"...  no
+checking for "leafpad"...  no
+checking for "mousepad"...  no
+checking for "xed"...  no
+checking for "notepad"...  no
+checking for "WinEdt"...  no
+checking for "WinShell"...  no
+checking for "PSPad"...  no
checking for gnumeric spreadsheet software...
+checking for "gnumeric"...  no
checking for an HTML previewer...
+checking for "firefox"...  yes
+checking for "mozilla"...  no
+checking for "netscape"...  no
checking for a BibTeX editor...
+checking for "jabref"...  no
+checking for "JabRef"...  no
+checking for "pybliographic"...  no
+checking for "bibdesk"...  no
+checking for "gbib"...  no
+checking for "kbib"...  no
+checking for "kbibtex"...  no
+checking for "sixpack"...  no
+checking for "bibedit"...  no
+checking for "tkbibtex"...  no
+checking for "TeXnicCenter"...  no
+checking for "xemacs"...  no
+checking for "gvim"...  yes
+checking for "kedit"...  no
+checking for "kwrite"...  no
+checking for "kate"...  no
+checking for "nedit"...  no
+checking for "gedit"...  no
+checking for "geany"...  no
+checking for "leafpad"...  no
+checking for "mousepad"...  no
+checking for "xed"...  no
+checking for "notepad"...  no
+checking for "WinEdt"...  no
+checking for "WinShell"...  no
+checking for "PSPad"...  no
checking for a Postscript previewer...
+checking for "kghostview"...  no
+checking for "okular"...  no
+checking for "qpdfview"...  no
+checking for "evince"...  yes
+checking for "xreader"...  no
+checking for "gv"...  no
+checking for "ghostview"...  no
+checking for "gsview64"...  no
+checking for "gsview32"...  no
checking for a PDF previewer...
+checking for "pdfview"...  no
+checking for "kpdf"...  no
+checking for "okular"...  no
+checking for "qpdfview"...  no
+checking for "evince"...  yes
+checking for "xreader"...  no
+checking for "kghostview"...  no
+checking for "xpdf"...  no
+checking for "SumatraPDF"...  no
+checking for "acrobat"...  no
+checking for "acroread"...  no
+checking for "mupdf"...  no
+checking for "Skim.app"...  no
+checking for "gv"...  no
+checking for "ghostview"...  no
+checking for "AcroRd32"...  no
+checking for "gsview64"...  no
+checking for "gsview32"...  no
checking for a DVI previewer...
+checking for "xdvi"...  yes
+checking for "kdvi"...  no
+checking for 

Re: LyX 2.4.0~RC4 does not launch under (GNOME) Wayland

[Cor Blom]

I see the same with some other Qt apps under gnome wayland. I'll submit 
a bug report with opensuse.


Cor

Op 25-04-2024 om 12:49 schreef Saša Janiška:

Hello!

I'm trying to use  LyX-2.4.0-RC$ under openSUSE Tumbleweed running
GNOME Wayland session.

When I launch it under Terminal, is just hangs...if I rm ~/.lyx I get:

$ lyx
LyX: Creating directory /home/gour/.lyx/
LyX: reconfiguring user directory
+Running LyX configure with Python 3.11.9
checking for a Latex2e program...
+checking for "latex"...  yes
checking for pLaTeX, the Japanese LaTeX...
+checking for "platex"...  not in path
checking for a java interpreter...
+checking for "java"...  yes
checking for a perl interpreter...
+checking for "perl"...  yes
checking for xsltproc...
+checking for "xsltproc"...  yes
/bin/sh: line 1: inkscape: command not found
checking for a Tgif viewer and editor...
+checking for "tgif"...  no
checking for a FIG viewer and editor...
+checking for "xfig"...  no
+checking for "jfig3-itext.jar"...  no
+checking for "jfig3.jar"...  no
checking for a Dia viewer and editor...
+checking for "dia"...  no
checking for an OpenDocument drawing viewer and editor...
+checking for "libreoffice"...  yes
+checking for "lodraw"...  yes
+checking for "ooffice"...  yes
+checking for "oodraw"...  yes
+checking for "soffice"...  yes
checking for a Grace viewer and editor...
+checking for "xmgrace"...  no
checking for a FEN viewer and editor...
+checking for "xboard"...  no
checking for a SVG viewer and editor...
+checking for "inkscape"...  no
checking for a raster image viewer...
+checking for "xv"...  no
+checking for "gwenview"...  no
+checking for "kview"...  no
+checking for "eog"...  yes
+checking for "xviewer"...  no
+checking for "ristretto"...  no
+checking for "gpicview"...  no
+checking for "lximage-qt"...  no
+checking for "xdg-open"...  yes
+checking for "gimp-remote"...  no
+checking for "gimp"...  yes
checking for a raster image editor...
+checking for "gimp-remote"...  no
+checking for "gimp"...  yes
checking for a text editor...
+checking for "xemacs"...  no
+checking for "gvim"...  yes
+checking for "kedit"...  no
+checking for "kwrite"...  no
+checking for "kate"...  no
+checking for "nedit"...  no
+checking for "gedit"...  no
+checking for "geany"...  no
+checking for "leafpad"...  no
+checking for "mousepad"...  no
+checking for "xed"...  no
+checking for "notepad"...  no
+checking for "WinEdt"...  no
+checking for "WinShell"...  no
+checking for "PSPad"...  no
checking for a lilypond editor...
+checking for "frescobaldi"...  no
+checking for "xemacs"...  no
+checking for "gvim"...  yes
+checking for "kedit"...  no
+checking for "kwrite"...  no
+checking for "kate"...  no
+checking for "nedit"...  no
+checking for "gedit"...  no
+checking for "geany"...  no
+checking for "leafpad"...  no
+checking for "mousepad"...  no
+checking for "xed"...  no
+checking for "notepad"...  no
+checking for "WinEdt"...  no
+checking for "WinShell"...  no
+checking for "PSPad"...  no
checking for gnumeric spreadsheet software...
+checking for "gnumeric"...  no
checking for an HTML previewer...
+checking for "firefox"...  yes
+checking for "mozilla"...  no
+checking for "netscape"...  no
checking for a BibTeX editor...
+checking for "jabref"...  no
+checking for "JabRef"...  no
+checking for "pybliographic"...  no
+checking for "bibdesk"...  no
+checking for "gbib"...  no
+checking for "kbib"...  no
+checking for "kbibtex"...  no
+checking for "sixpack"...  no
+checking for "bibedit"...  no
+checking for "tkbibtex"...  no
+checking for "TeXnicCenter"...  no
+checking for "xemacs"...  no
+checking for "gvim"...  yes
+checking for "kedit"...  no
+checking for "kwrite"...  no
+checking for "kate"...  no
+checking for "nedit"...  no
+checking for "gedit"...  no
+checking for "geany"...  no
+checking for "leafpad"...  no
+checking for "mousepad"...  no
+checking for "xed"...  no
+checking for "notepad"...  no
+checking for "WinEdt"...  no
+checking for "WinShell"...  no
+checking for "PSPad"...  no
checking for a Postscript previewer...
+checking for "kghostview"...  no
+checking for "okular"...  no
+checking for "qpdfview"...  no
+checking for "evince"...  yes
+checking for "xreader"...  no
+checking for "gv"...  no
+checking for "ghostview"...  no
+checking for "gsview64"...  no
+checking for "gsview32"...  no
checking for a PDF previewer...
+checking for "pdfview"...  no
+checking for "kpdf"...  no
+checking for "okular"...  no
+checking for "qpdfview"...  no
+checking for "evince"...  yes
+checking for "xreader"...  no
+checking for "kghostview"...  no
+checking for "xpdf"...  no
+checking for "SumatraPDF"...  no
+checking for "acrobat"...  no
+checking for "acroread"...  no
+checking for "mupdf"...  no
+checking for "Skim.app"...  no
+checking for "gv"...  no
+checking for "ghostview"...  no
+checking for "AcroRd32"...  no
+checking for "gsview64"...  no
+checking for "gsview32"...  no
checking for a DVI previewer...
+checking for 

Re: LyX 2.4.0~RC4 does not launch under (GNOME) Wayland

[Cor Blom]

Op 25-04-2024 om 12:49 schreef Saša Janiška:

I'm trying to use  LyX-2.4.0-RC$ under openSUSE Tumbleweed running
GNOME Wayland session.

When I launch it under Terminal, is just hangs...


I cannot reproduce exactly but partly. When I try to launch lyx from the 
gui, I don't get a window, but somewhere lyx is running. When I launch 
it from the commandline, it does work.


In kde plasma everything works fine under wayland.

This all on openSUSE Tumbleweed.

You can add "QT_QPA_PLATFORM=xcb" before the command "lyx", which forces 
xwayland.


Cor



BTW: it was not the intention to have RC4 already in tumbleweed, but it 
slipped through with Easter. Reverting would cause more problems, I think.

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

2.4 ready for wayland??

[Cor Blom]

Hi all,
I wonder how you see the transition to wayland. There are two bugs that 
I think need to be resolved:


https://www.lyx.org/trac/ticket/12614

https://www.lyx.org/trac/ticket/13039

Personally I don't think these are showstopper that need to be resolved 
before release, but then some note about lyx not completely ready for 
wayland would be a good idea. Maybe with a workaround to force lyx to 
run in xwayland, which works fine.


Kind regards,

Cor



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

Re: LyX 2.4.0 RC3

[Cor Blom]

Op 11-02-2024 om 22:41 schreef Richard Kimberly Heck:
Please report any problems to lyx-devel@lists.lyx.org, which you should 
be able to do by replying to this message.




openSUSE Tumbleweed, plasma 5 and 6 RC2, wayland scaled, lyx compiled 
against qt6.


I see problems with the workarea, that does not scale as the rest of the 
desktop does. I tested 110% and 125%. The interface itself scales fine, 
but not the workarea (that space where we type the text).


At 100% all is working fine. Also under X11 it is working fine, even 
when scaled. So this is not a dealbreaker. I can file a bug if you want 
to push this to the longer term.


Thanks for all the work,

Cor

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

Re: LyX 2.4.0, Release Candidate 1

[Cor Blom]

Op 15-01-2024 om 21:40 schreef Richard Kimberly Heck:
The LyX team is happy (and relieved) to announce the publication of the 
first 'release candidate' for the long awaited 2.4.0. You can find 
tarballs and binaries for Windows and OSX here:


     http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/

Strictly speaking, we are releasing RC1 for testing purposes only. 
Please report any bugs you may find to the user list or the developer 
list, as you prefer.


That said, many of us have been using the development branch for 
production work, and we believe it is pretty stable. Remember, however, 
that files saved with 2.4 cannot be opened in LyX 2.3.x unless you first 
export them to that format.


Riki




Those on opensuse can find packages here:

https://download.opensuse.org/repositories/Publishing/

This is a testing project. With the release of 2.4.0 final it will move 
to Tumbleweed and future Leap 15.6. The version for Tumbleweed has 
switched to using Qt 6.


Packaging or opensuse specific bugs can be reported at

https://bugzilla.opensuse.org/

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

Re: flatpak

[Cor Blom]

Op 26-11-2023 om 05:48 schreef Richard Kimberly Heck:
It's fine to edit lyxrc.defaults, I think. This is basically a normal 
thing for distributions to do, though there may be some better way to do 
it. Perhaps someone else will know.


I use lyxrc.dist for distribution specific settings.

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

Re: metainfo and cmake

[Cor Blom]

Op 06-10-2023 om 12:14 schreef Kornel Benko:

Am Fri, 06 Oct 2023 10:53:25 +0100
schrieb José Matos :


On Fri, 2023-10-06 at 11:09 +0200, Kornel Benko wrote:

Should we rename this file on install to be able to install multiple
lyx-versions?
Like "org.lyx.LyX.metainfo.xml" -> "LyX2.4.metainfo.xml"
if using versioned suffixes?

Kornel


Using my blue hat here (Fedora). :-)

Although I am not using cmake (yet!) I prefer to have the simple
version. When I need to take care of another version I prefer to do it
myself.

Looking into the system directory (/usr/share/metainfo/) I do not see
any versioned file.

My two ¢.


I am using lyx2.3 and lyx2.4 in parallel installed. The problem will arise on 
installing
lyx2.5 later.

Installing without using the suffix should be no problem for you (e.g. no 
change)
My proposal would rename it to "LyX.metainfo.xml".



This conflict is, I believe, also present in autoconf builds. The 
default there is to build without suffix. If I move to cmake for 
openSUSE packages, it's very likely I will continue to build without suffix.


Cor

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

metainfo and cmake

[Cor Blom]

Hi,

autoconf installs org.lyx.LyX.metainfo.xml automatically, but cmake does 
not. Intention, mistake, ...?


This is on openSUSE, building rpms using the buildservice.

Thanks,

Cor

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

Re: Beta 4 Tarballs

[Cor Blom]

Op 29-08-2023 om 02:47 schreef Richard Kimberly Heck:

Beta 4 tarballs are here:

http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/

Please prepare the binaries!

The hope is to freeze strings soon, once we confirm that some of the 
fixes in this release work. We'll see.


Riki




For those on openSUSE I build regularly git snapshots. For upcoming 2.4 
I do so both against qt5 and qt6 and they should be co-installable 
besides "normal" lyx (if not, let me know, because then there is a 
mistake I should correct). See:


https://download.opensuse.org/repositories/home:/cornelisbb:/lyx-unstable/

Cor

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

Fwd: qt6, autoconf and lyx: help wanted

[Cor Blom]

Hi,

Below the answer on my request for help.

osc build is what I have used throughout and what is used to build the 
packages for openSUSE. Adding qt6-gui-private-devel does solve the error 
and the package now builds fine.


Configure should probably fail if that library is not found.

Thanks,

Cor

 Doorgestuurd bericht 
Onderwerp: Re: qt6, autoconf and lyx: help wanted
Datum: Sat, 26 Aug 2023 13:51:52 +0200
Van: Fabian Vogt 
Aan: fact...@lists.opensuse.org
CC: Cor Blom 

Moin,

Am Samstag, 26. August 2023, 11:00:58 CEST schrieb Cor Blom:

Hi all,

I have a problem compiling lyx against qt6, both locally on my machine 
and in the buildservice. You can find the project here:


https://build.opensuse.org/package/show/home:cornelisbb:lyx-unstable/lyx-qt6


I tried to build it locally with the same ./configure and it worked fine,
only in an osc build it failed. My hypothesis was that it somehow relied on
more devel packages implicitly, maybe private headers. I patched 
config/qt.m4

to not delete the test.pro file and the error became obvious:

abuild@fabians-envy:/tmp/tmp.StnZiPAtl6> qmake6 test.pro
Project ERROR: Unknown module(s) in QT: gui-private

This is because of:

qtHaveModule(gui)   {QT += gui gui-private} else {MISSING += 
gui}


Does LyX really need gui-private? If not, just remove the "gui-private" part
here. If it does, use

qtHaveModule(gui-private)   {QT += gui-private} else {MISSING += 
gui-private}


and add BuildRequires: qt6-gui-private-devel

There's another bug FWICT:

[   16s] checking for QtGui/qtgui-config.h... yes
[   16s] checking for QtGui/private/qtgui-config_p.h... no
[   16s] checking whether Qt uses the X Window system... no

but

~> grep -R QT_FEATURE_xcb /usr/include/qt6
/usr/include/qt6/QtGui/qtgui-config.h:#define QT_FEATURE_xcb 1

Cheers,
Fabian

I have asked the lyx devs for help, but they are baffled. It seems that 
qt6 on openSUSE behaves unexpected. It works find with cmake, though. 
(Yes, lyx supports both.)


In the end I was asked to execute "qmake6 test.pro" (test.pro was a file 
they provided). It should provide a Makefile, but it did not. Nothing 
happened.


Can someone provide some insight here? Are there programs in qt6 in OBS 
that use autoconf, so that I have something to compare? It seems there 
is something wrong with autoconf.


The specific error is that files in the subdirectories of 
/usr/include/qt6 cannot be found. If I link the files into 
/usr/include/qt6 itself, they are found. Nothing strange is found in the 
config phase. Only during compilation. The error message is:


[   38s]   GEN  moc_Validator.cpp
[   38s] make  all-am
[   38s] make[6]: Entering directory 
'/home/abuild/rpmbuild/BUILD/lyx-qt6-2.4.1692654261.fe74c24da9/src/frontends/qt'

[   38s]   CXX  ButtonPolicy.o
[   38s]   CXX  Dialog.o
[   38s]   CXX  DialogFactory.o
[   38s]   CXX  Action.o
[   38s] In file included from FindAndReplace.h:15,
[   38s]  from DialogFactory.cpp:14:
[   38s] DockView.h:17:10: fatal error: QDockWidget: No such file or 
directory

[   38s]17 | #include 
[   38s]   |  ^
[   38s] In file included from Dialog.cpp:15:
[   38s] GuiView.h:22:10: fatal error: QMainWindow: No such file or 
directory

[   38s]22 | #include 
[   38s]   |  ^
[   38s] compilation terminated.

Any help would be much appreciated.

Thanks,

Cor






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

Re: Error with Qt 6 and autotools

[Cor Blom]

Op 26-08-2023 om 01:52 schreef Jean-Marc Lasgouttes:

Le 25/08/2023 à 22:08, Cor Blom a écrit :

Sorry, no change. I give up.


Maybe you could just try to ask the suse/qt people why qmake6 does not 
produce a Makefile in this case?


JMarc



Done. Waiting for any response.

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

Re: Error with Qt 6 and autotools

[Cor Blom]

Op 25-08-2023 om 21:53 schreef Enrico Forestieri:

On Fri, Aug 25, 2023 at 08:45:41PM +0200, Cor Blom wrote:

Op 25-08-2023 om 17:58 schreef Enrico Forestieri:

On Fri, Aug 25, 2023 at 03:32:50PM +0200, Cor Blom wrote:


Op 25-08-2023 om 13:01 schreef Enrico Forestieri:

After that, please report the output of the following commands:

$ make -s INCPATH
$ make -s LIBS
$ make -s EXPORT_MISSING


For all I get:

make: *** No rule to make target etc.

What am I missing?


Do you get a Makefile after issuing the command "qmake6 test.pro"?
If yes, please send it as an attachment, otherwise I am baffled.



One last effort: I did first:

$ qmake6 -project


This simply creates .pro (curdir being the name of the current 
directory) that in turn includes test.pro. Thus, this is an unnecessary 
step.



Then I did

$ qmake6 test.pro

The other commands still gave the message "No rule to make target etc."

I did get a Makefile. See attached.


The Makefile you get is not related to the test.pro file I attached 
previously. Please, make sure that test.pro is not an empty file (I also 
get a useless Makefile by using an empty test.pro). For your 
convenience, I am attaching again the test.pro file.





Sorry, no change. I give up.

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

Re: Error with Qt 6 and autotools

[Cor Blom]

Op 25-08-2023 om 17:58 schreef Enrico Forestieri:

On Fri, Aug 25, 2023 at 03:32:50PM +0200, Cor Blom wrote:


Op 25-08-2023 om 13:01 schreef Enrico Forestieri:

After that, please report the output of the following commands:

$ make -s INCPATH
$ make -s LIBS
$ make -s EXPORT_MISSING


For all I get:

make: *** No rule to make target etc.

What am I missing?


Do you get a Makefile after issuing the command "qmake6 test.pro"?
If yes, please send it as an attachment, otherwise I am baffled.



One last effort: I did first:

$ qmake6 -project

Then I did

$ qmake6 test.pro

The other commands still gave the message "No rule to make target etc."

I did get a Makefile. See attached.

Cor#
# Makefile for building: test
# Generated by qmake (3.1) (Qt 6.5.2)
# Project:  test.pro
# Template: app
# Command: /bin/qmake6 -o Makefile test.pro
#

MAKEFILE  = Makefile

EQ= =

### Compiler, tools and options

CC= gcc
CXX   = g++
DEFINES   = -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB
CFLAGS= -pipe -O2 -Wall -Wextra -D_REENTRANT $(DEFINES)
CXXFLAGS  = -pipe -O2 -Wall -Wextra -D_REENTRANT $(DEFINES)
INCPATH   = -I. -I. -I/usr/include/qt6 -I/usr/include/qt6/QtGui 
-I/usr/include/qt6/QtCore -I. -I/usr/lib64/qt6/mkspecs/linux-g++
QMAKE = /bin/qmake6
DEL_FILE  = rm -f
CHK_DIR_EXISTS= test -d
MKDIR = mkdir -p
COPY  = cp -f
COPY_FILE = cp -f
COPY_DIR  = cp -f -R
INSTALL_FILE  = install -m 644 -p
INSTALL_PROGRAM = install -m 755 -p
INSTALL_DIR   = cp -f -R
QINSTALL  = /bin/qmake6 -install qinstall
QINSTALL_PROGRAM = /bin/qmake6 -install qinstall -exe
DEL_FILE  = rm -f
SYMLINK   = ln -f -s
DEL_DIR   = rmdir
MOVE  = mv -f
TAR   = tar -cf
COMPRESS  = gzip -9f
DISTNAME  = test1.0.0
DISTDIR = /home/abuild/test/.tmp/test1.0.0
LINK  = g++
LFLAGS= -Wl,-O1 -Wl,-rpath,/usr/lib64 -Wl,-rpath-link,/usr/lib64
LIBS  = $(SUBLIBS) /usr/lib64/libQt6Gui.so /usr/lib64/libGLX.so 
/usr/lib64/libOpenGL.so /usr/lib64/libQt6Core.so -lpthread -lGL   
AR= ar cqs
RANLIB= 
SED   = sed
STRIP = strip

### Output directory

OBJECTS_DIR   = ./

### Files

SOURCES   =  
OBJECTS   = 
DIST  = /usr/lib64/qt6/mkspecs/features/spec_pre.prf \
/usr/lib64/qt6/mkspecs/common/unix.conf \
/usr/lib64/qt6/mkspecs/common/linux.conf \
/usr/lib64/qt6/mkspecs/common/sanitize.conf \
/usr/lib64/qt6/mkspecs/common/gcc-base.conf \
/usr/lib64/qt6/mkspecs/common/gcc-base-unix.conf \
/usr/lib64/qt6/mkspecs/common/g++-base.conf \
/usr/lib64/qt6/mkspecs/common/g++-unix.conf \
/usr/lib64/qt6/mkspecs/qconfig.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_concurrent.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_core.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_core5compat.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_core_private.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_dbus.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_gui.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_printsupport.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_sql.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_svg.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_svgwidgets.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_widgets.pri \
/usr/lib64/qt6/mkspecs/modules/qt_lib_xml.pri \
/usr/lib64/qt6/mkspecs/features/qt_functions.prf \
/usr/lib64/qt6/mkspecs/features/qt_config.prf \
/usr/lib64/qt6/mkspecs/linux-g++/qmake.conf \
/usr/lib64/qt6/mkspecs/features/spec_post.prf \
/usr/lib64/qt6/mkspecs/features/exclusive_builds.prf \
/usr/lib64/qt6/mkspecs/features/toolchain.prf \
/usr/lib64/qt6/mkspecs/features/default_pre.prf \
/usr/lib64/qt6/mkspecs/features/resolve_config.prf \
/usr/lib64/qt6/mkspecs/features/default_post.prf \
/usr/lib64/qt6/mkspecs/features/warn_on.prf \
/usr/lib64/qt6/mkspecs/features/qt.prf \
/usr/lib64/qt6/mkspecs/features/resources_functions.prf \
/usr/lib64/qt6/mkspecs/features/resources.prf \
/usr/lib64/qt6/mkspecs/features/moc.prf \
/usr/lib64/qt6/mkspecs/features/link_ltcg.prf \
/usr/lib64/qt6/mkspecs/features/unix/opengl.prf \
/usr/lib64/qt6/mkspecs/features/unix/thread.prf \
/usr/lib64/qt6/mkspecs/features/qmake_use.prf \
/u

Re: Error with Qt 6 and autotools

[Cor Blom]

Op 25-08-2023 om 17:58 schreef Enrico Forestieri:

On Fri, Aug 25, 2023 at 03:32:50PM +0200, Cor Blom wrote:


Op 25-08-2023 om 13:01 schreef Enrico Forestieri:

After that, please report the output of the following commands:

$ make -s INCPATH
$ make -s LIBS
$ make -s EXPORT_MISSING


For all I get:

make: *** No rule to make target etc.

What am I missing?


Do you get a Makefile after issuing the command "qmake6 test.pro"?
If yes, please send it as an attachment, otherwise I am baffled.



One additional remark: I build everything in the opensuse buildservice. 
If there is a fault on my side, it is in the way Qt6 is 
packaged/configured in openSUSE. (or I need to add a additional package 
that I knowing nothing about). If you think that's the case, I can ask 
on the opensuse mailinglist. There are Qt experts there.


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

Re: Error with Qt 6 and autotools

[Cor Blom]

Op 25-08-2023 om 17:58 schreef Enrico Forestieri:

On Fri, Aug 25, 2023 at 03:32:50PM +0200, Cor Blom wrote:


Op 25-08-2023 om 13:01 schreef Enrico Forestieri:

After that, please report the output of the following commands:

$ make -s INCPATH
$ make -s LIBS
$ make -s EXPORT_MISSING


For all I get:

make: *** No rule to make target etc.

What am I missing?


Do you get a Makefile after issuing the command "qmake6 test.pro"?
If yes, please send it as an attachment, otherwise I am baffled.



Sorry, no.

I can build the package with cmake, so I can do some testing the coming 
months in spite of this problem.


I leave it at this for now then, but if some testing is needed, let me know.

Thanks,

Cor

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

Re: Error with Qt 6 and autotools

[Cor Blom]

Op 25-08-2023 om 13:01 schreef Enrico Forestieri:

After that, please report the output of the following commands:

$ make -s INCPATH
$ make -s LIBS
$ make -s EXPORT_MISSING


For all I get:

make: *** No rule to make target etc.

What am I missing?

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

Re: Error with Qt 6 and autotools

[Cor Blom]

[   45s] make  all-am [   45s] make[6]: Entering directory
'/home/abuild/rpmbuild/BUILD/lyx-qt6-2.4.1692654261.fe74c24da9/src/frontends/qt'

[   45s]   CXX  ButtonPolicy.o
[   45s]   CXX  Dialog.o [   45s]   CXX  DialogFactory.o [
45s]   CXX  Action.o [   45s] In file included from
Dialog.cpp:15: [   45s] GuiView.h:22:10: fatal error: QMainWindow: No
such file or directory [   45s]22 | #include  [
45s]   |  ^ [   45s] compilation terminated. 
[   45s] make[6]: *** [Makefile:1015: Dialog.o] Error 1 [   45s]

make[6]: *** Waiting for unfinished jobs [   45s] In file
included from FindAndReplace.h:15, [   45s]  from
DialogFactory.cpp:14: [   45s] DockView.h:17:10: fatal error:
QDockWidget: No such file or directory [   45s]17 | #include
 [   45s]   |  ^ [   45s]
compilation terminated. [   45s] make[6]: *** [Makefile:1015:
DialogFactory.o] Error 1 [   45s] In file included from
Action.cpp:14: [   45s] GuiApplication.h:21:10: fatal error:
QApplication: No such file or directory [   45s]21 | #include
 [   45s]   |  ^~ [   45s]
compilation terminated.


I tried something, looking at what could not be found. Those files are
not immediately under /usr/include/qt6 but in their respective
subfolders: QtConcurrent, QtWidgets, QtSvg and QtSvgWidgets. So I linked
the content of those folders to /usr/include/qt6 The result is that
compilation passes the place of the error above. (Later there is an
error, but I assume this has to do with my messing with the files.)

In CMakeLists.text there is the following line, which possibly makes it
work with cmake:

if(Qt6Core_FOUND)
   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg
SvgWidgets)

Maybe this helps?

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

Re: Error with Qt 6 and autotools

[Cor Blom]

Op 24-08-2023 om 13:49 schreef Jean-Marc Lasgouttes:

Le 24/08/2023 à 13:27, Cor Blom a écrit :

Can I see src/frontends/qt/Makefile too?


See attached. I use a recent git checkout, so it should be the same as 
the one in the git sources.


I meant the generated Makefile.



Ah, sorry. Attached.

Cor# Makefile.in generated by automake 1.16.5 from Makefile.am.
# src/frontends/qt/Makefile.  Generated from Makefile.in by configure.

# Copyright (C) 1994-2021 Free Software Foundation, Inc.

# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.




am__is_gnu_make = { \
  if test -z '$(MAKELEVEL)'; then \
false; \
  elif test -n '$(MAKE_HOST)'; then \
true; \
  elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
true; \
  else \
false; \
  fi; \
}
am__make_running_with_option = \
  case $${target_option-} in \
  ?) ;; \
  *) echo "am__make_running_with_option: internal error: invalid" \
  "target option '$${target_option-}' specified" >&2; \
 exit 1;; \
  esac; \
  has_opt=no; \
  sane_makeflags=$$MAKEFLAGS; \
  if $(am__is_gnu_make); then \
sane_makeflags=$$MFLAGS; \
  else \
case $$MAKEFLAGS in \
  *\\[\ \   ]*) \
bs=\\; \
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
  | sed "s/$$bs$$bs[$$bs $$bs   ]*//g"`;; \
esac; \
  fi; \
  skip_next=no; \
  strip_trailopt () \
  { \
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
  }; \
  for flg in $$sane_makeflags; do \
test $$skip_next = yes && { skip_next=no; continue; }; \
case $$flg in \
  *=*|--*) continue;; \
-*I) strip_trailopt 'I'; skip_next=yes;; \
  -*I?*) strip_trailopt 'I';; \
-*O) strip_trailopt 'O'; skip_next=yes;; \
  -*O?*) strip_trailopt 'O';; \
-*l) strip_trailopt 'l'; skip_next=yes;; \
  -*l?*) strip_trailopt 'l';; \
  -[dEDm]) skip_next=yes;; \
  -[JT]) skip_next=yes;; \
esac; \
case $$flg in \
  *$$target_option*) has_opt=yes; break;; \
esac; \
  done; \
  test $$has_opt = yes
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
pkgincludedir = $(includedir)/lyx
pkglibdir = $(libdir)/lyx
pkglibexecdir = $(libexecdir)/lyx
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)
transform = $(program_transform_name)
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = x86_64-suse-linux-gnu
host_triplet = x86_64-suse-linux-gnu
target_triplet = x86_64-suse-linux-gnu
subdir = src/frontends/qt
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/config/lyxinclude.m4 \
$(top_srcdir)/config/lyxpython.m4 $(top_srcdir)/config/pkg.m4 \
$(top_srcdir)/config/qt.m4 $(top_srcdir)/config/spell.m4 \
$(top_srcdir)/m4/ax_check_compile_flag.m4 \
$(top_srcdir)/m4/eilseq.m4 $(top_srcdir)/m4/iconv.m4 \
$(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \
$(top_srcdir)/m4/lib-prefix.m4 $(top_srcdir)/m4/nls.m4 \
$(top_srcdir)/m4/po.m4 $(top_srcdir)/m4/progtest.m4 \
$(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
DIST_COMMON = $(srcdir)/Makefile.am $(am__DIST_COMMON)
mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = $(top_builddir)/config.h
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
LIBRARIES = $(noinst_LIBRARIES)
AM_V_AR = $(am__v_AR_$(V))
am__v_AR_ = $(am__v_AR_$(AM_DEFAULT_VERBOSITY))
am__v_AR_0 = @echo "  AR  " $@;
am__v_AR_1 = 
liblyxqt_a_AR = $(AR) $(ARFLAGS)
liblyxqt_a_LIBADD =
am__objects_1 = ButtonPolicy.$(OBJEXT) Dialog.$(OBJEXT) \
DialogFactory.$(OBJEXT) Action.$(OBJEXT) \
BulletsModule.$(OBJEXT) ButtonController.$(OBJEXT) \
CategorizedCombo.$(OBJEXT) ColorCache.$(OBJEXT) \
CustomizedWidgets.$(OBJEXT) DialogView.$(OBJEXT) \
DockView.$(OBJEXT) EmptyTable.$(OBJEXT) \
FancyLineEdit.$(OBJEXT) FileDialog.$(OBJEXT) \
FindAndReplace.$(OBJEXT) FloatPlacement.$(OBJEXT) \
GuiAbout.$(OBJEXT) GuiAlert.$(OBJEXT) GuiApplication.$(OBJEXT) \
GuiBibitem.$(OBJEXT) GuiBibtex.$(OBJEXT) GuiBox.$(OBJEXT) \
GuiBranch.$(OBJEXT) GuiBranches.$(OBJEXT) GuiChanges.$(OBJEXT) \
 

Re: Error with Qt 6 and autotools

[Cor Blom]

Op 24-08-2023 om 13:09 schreef Jean-Marc Lasgouttes:

Le 24/08/2023 à 09:38, Cor Blom a écrit :

Op 24-08-2023 om 00:50 schreef Jean-Marc Lasgouttes:
Do you have a config.log? The configure mechanism for qt6 now relies 
on qmake, so there may be quirks.


[   22s] run "./configure && make"
[   22s]
[   22s] + TEXMF=/usr/share/texmf
[   22s] + CONFIG_SHELL=/usr/bin/bash
[   22s] + export CONFIG_SHELL

...

Thanks. There is nothing obviously wrong here.

Can I see src/frontends/qt/Makefile too?



See attached. I use a recent git checkout, so it should be the same as 
the one in the git sources.


Cor
include $(top_srcdir)/config/common.am

BUILT_SOURCES = $(UIFILES:%.ui=ui_%.h)
BUILT_SOURCES += $(MOCEDFILES)

CLEANFILES = $(BUILT_SOURCES)

#  Qt stuff  #
# Use _() for localization instead of tr() or trUtf8()
UICFLAGS=-tr lyx::qt_

# The ui_%.h pattern must match the filter in ../../../po/Rules-lyx
ui_%.h: ui/%.ui
$(AM_V_GEN)$(QT_UIC) $(UICFLAGS) $< -o $@

MOCEDFILES = $(MOCHEADER:%.h=moc_%.cpp)

QT_VERSION = $(shell IFS=.; set -- `echo $(QTLIB_VERSION)`; \
 echo 0x0`echo "obase=16; $$1*65536+$$2*256+$$3" | bc`)

# The moc_%.cpp pattern must match the filter in ../../../po/Rules-lyx
moc_%.cpp: %.h
$(AM_V_GEN)$(QT_MOC) -DQT_VERSION=$(QT_VERSION) -o $@ $<


#  LIBRARIES  #

noinst_LIBRARIES = liblyxqt.a

liblyxqt_a_DEPENDENCIES = $(MOCEDFILES)

AM_CPPFLAGS += \
$(QT_CPPFLAGS) \
-DQT_NO_CAST_TO_ASCII \
-DQT_NO_STL \
-I$(top_srcdir)/src \
-I$(top_srcdir)/src/frontends \
-I$(top_srcdir)/images \
$(QT_INCLUDES) \
$(BOOST_INCLUDES) $(ICONV_INCLUDES) $(ZLIB_INCLUDES) $(NOD_INCLUDES)

SOURCEFILES = \
ButtonPolicy.cpp \
ButtonPolicy.h \
Dialog.cpp \
DialogFactory.cpp \
Action.cpp \
BulletsModule.cpp \
ButtonController.cpp \
CategorizedCombo.cpp \
ColorCache.cpp \
CustomizedWidgets.cpp \
DialogView.cpp \
DockView.cpp \
EmptyTable.cpp \
FancyLineEdit.cpp \
FileDialog.cpp \
FindAndReplace.cpp \
FloatPlacement.cpp \
GuiAbout.cpp \
GuiAlert.cpp \
GuiApplication.cpp \
GuiBibitem.cpp \
GuiBibtex.cpp \
GuiBox.cpp \
GuiBranch.cpp \
GuiBranches.cpp \
GuiChanges.cpp \
GuiCharacter.cpp \
GuiCitation.cpp \
GuiClickableLabel.cpp \
GuiClipboard.cpp \
GuiCommandBuffer.cpp \
GuiCommandEdit.cpp \
GuiCompare.cpp \
GuiCompareHistory.cpp \
GuiCompleter.cpp \
GuiCounter.cpp \
GuiDelimiter.cpp \
GuiDialog.cpp \
GuiDocument.cpp \
GuiErrorList.cpp \
GuiERT.cpp \
GuiExternal.cpp \
GuiFontExample.cpp \
GuiFontLoader.cpp \
GuiFontMetrics.cpp \
GuiGraphics.cpp \
GuiHSpace.cpp \
GuiHyperlink.cpp \
GuiIdListModel.cpp \
GuiImage.cpp \
GuiInclude.cpp \
GuiIndex.cpp \
GuiIndices.cpp \
GuiInfo.cpp \
GuiKeySymbol.cpp \
GuiLabel.cpp \
GuiLine.cpp \
GuiListings.cpp \
GuiLog.cpp \
GuiLyXFiles.cpp \
GuiMathMatrix.cpp \
GuiNomenclature.cpp \
GuiNote.cpp \
GuiPainter.cpp \
GuiParagraph.cpp \
GuiPhantom.cpp \
GuiPrefs.cpp \
GuiPrintindex.cpp \
GuiPrintNomencl.cpp \
GuiProgress.cpp \
GuiProgressView.cpp \
GuiRef.cpp \
GuiSearch.cpp \
GuiSelection.cpp \
GuiSelectionManager.cpp \
GuiSendto.cpp \
GuiSetBorder.cpp \
GuiShowFile.cpp \
GuiSpellchecker.cpp \
GuiSymbols.cpp \
GuiTabular.cpp \
GuiTabularCreate.cpp \
GuiTexinfo.cpp \
GuiThesaurus.cpp \
GuiToc.cpp \
GuiToolbar.cpp \
GuiView.cpp \
GuiViewSource.cpp \
GuiVSpace.cpp \
GuiWorkArea.cpp \
GuiWrap.cpp \
IconPalette.cpp \
InGuiThread.cpp \
InsertTableWidget.cpp \
InsetParamsDialog.cpp \
InsetParamsWidget.cpp \
LengthCombo.cpp \
LyXFileDialog.cpp \
LaTeXHighlighter.cpp \
LayoutBox.cpp \
Menus.cpp \
PanelStack.cpp \
qt_helpers.cpp \
TocModel.cpp \
TocWidget.cpp \
Toolbars.cpp \
ToolTipFormatter.cpp \
Validator.cpp

NOMOCHEADER = \
ButtonController.h \
ColorCache.h \
Dialog.h \
DialogFactory.h \
FileDialog.h \
GuiFontExample.h \
GuiFontLoader.h \
GuiFontMetrics.h \
GuiIdListModel.h \
GuiImage.h \
GuiKeySymbol.h \
GuiPainter

Re: Error with Qt 6 and autotools

[Cor Blom]

Op 24-08-2023 om 00:50 schreef Jean-Marc Lasgouttes:
Do you have a config.log? The configure mechanism for qt6 now relies on 
qmake, so there may be quirks.


[   22s] run "./configure && make"
[   22s]
[   22s] + TEXMF=/usr/share/texmf
[   22s] + CONFIG_SHELL=/usr/bin/bash
[   22s] + export CONFIG_SHELL
[   22s] + CFLAGS='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fstack-clash-protection -Werror=return-type -flto=auto -g'

[   22s] + export CFLAGS
[   22s] + CXXFLAGS='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fstack-clash-protection -Werror=return-type -flto=auto -g'

[   22s] + export CXXFLAGS
[   22s] + FFLAGS='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fstack-clash-protection -Werror=return-type -flto=auto -g '

[   22s] + export FFLAGS
[   22s] + FCFLAGS='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fstack-clash-protection -Werror=return-type -flto=auto -g '

[   22s] + export FCFLAGS
[   22s] + LDFLAGS=-flto=auto
[   22s] + export LDFLAGS
[   22s] + ./configure --host=x86_64-suse-linux-gnu 
--build=x86_64-suse-linux-gnu --program-prefix= 
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr 
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
--mandir=/usr/share/man --infodir=/usr/share/info 
--enable-build-type=rel --without-aspell --with-hunspell --with-enchant 
--enable-qt6

[   22s] configuring LyX version 2.4.0~RC1.devel
[   22s] checking for build type... release
[   22s] checking for version suffix...
[   22s] checking whether Qt6 is requested... yes
[   22s] checking build system type... x86_64-suse-linux-gnu
[   22s] checking host system type... x86_64-suse-linux-gnu
[   22s] checking target system type... x86_64-suse-linux-gnu
[   22s] checking what packaging should be used... posix
[   22s] checking whether to enable maintainer-specific portions of 
Makefiles... no

[   22s] checking whether make supports nested variables... yes
[   22s] checking for a BSD-compatible install... /usr/bin/install -c
[   22s] checking whether build environment is sane... yes
[   22s] checking for a race-free mkdir -p... /usr/bin/mkdir -p
[   22s] checking for gawk... gawk
[   22s] checking whether make sets $(MAKE)... yes
[   22s] checking whether UID '399' is supported by ustar format... yes
[   22s] checking whether GID '399' is supported by ustar format... yes
[   22s] checking how to create a ustar tar archive... gnutar
[   22s] checking for a Python interpreter with version >= 2.7.0 or 
3.5.0... python3

[   22s] checking for python3... /usr/bin/python3
[   22s] checking for python version... 3.11
[   22s] checking for python platform... linux
[   22s] checking for GNU default python prefix... ${prefix}
[   22s] checking for GNU default python exec_prefix... ${exec_prefix}
[   22s] checking for python script directory (pythondir)... 
${PYTHON_PREFIX}/lib/python3.11/site-packages
[   22s] checking for python extension module directory (pyexecdir)... 
${PYTHON_EXEC_PREFIX}/lib64/python3.11/site-packages
[   22s] checking whether make supports the include directive... yes 
(GNU style)

[   22s] checking for x86_64-suse-linux-gnu-gcc... no
[   22s] checking for gcc... gcc
[   22s] checking whether the C compiler works... yes
[   22s] checking for C compiler default output file name... a.out
[   22s] checking for suffix of executables...
[   22s] checking whether we are cross compiling... no
[   22s] checking for suffix of object files... o
[   22s] checking whether the compiler supports GNU C... yes
[   22s] checking whether gcc accepts -g... yes
[   22s] checking for gcc option to enable C11 features... none needed
[   23s] checking whether gcc understands -c and -o together... yes
[   23s] checking dependency style of gcc... none
[   23s] checking for x86_64-suse-linux-gnu-ar... no
[   23s] checking for x86_64-suse-linux-gnu-lib... no
[   23s] checking for x86_64-suse-linux-gnu-link... no
[   23s] checking for ar... ar
[   23s] checking the archiver (ar) interface... ar
[   23s] checking for x86_64-suse-linux-gnu-ranlib... no
[   23s] checking for ranlib... ranlib
[   23s] checking for x86_64-suse-linux-gnu-g++... no
[   23s] checking for x86_64-suse-linux-gnu-c++... no
[   23s] checking for x86_64-suse-linux-gnu-gpp... no
[   23s] checking for x86_64-suse-linux-gnu-aCC... no
[   23s] checking for x86_64-suse-linux-gnu-CC... no
[   23s] checking for x86_64-suse-linux-gnu-cxx... no
[   23s] checking for x86_64-suse-linux-gnu-cc++... no
[   23s] checking for x86_64-suse-linux-gnu-cl.exe... no
[   23s] checking for x86_64-suse-linux-gnu-FCC... no
[ 

Re: Error with Qt 6 and autotools

[Cor Blom]

Op 22-08-2023 om 21:02 schreef Scott Kostyshak:

Are you sure that CMake ends up compiling with Qt 6? I wonder if it's
possible CMake actually compiles with Qt 5 (because it detects a missing
dependency).


It's an isolated build environment where qt5 is not present, so yes it 
is using qt6.


I also see this among the build param:

LYX_USE_QT:STRING  = QT6: Use Qt version as frontend 
(AUTO QT5 QT6)


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

Error with Qt 6 and autotools

[Cor Blom]

Hi,

I have tried building the qt6 version using autotools in the 
buildservice of openSUSE for Tumbleweed. It fails with the following error:


[   45s] make  all-am
[   45s] make[6]: Entering directory 
'/home/abuild/rpmbuild/BUILD/lyx-qt6-2.4.1692654261.fe74c24da9/src/frontends/qt'

[   45s]   CXX  ButtonPolicy.o
[   45s]   CXX  Dialog.o
[   45s]   CXX  DialogFactory.o
[   45s]   CXX  Action.o
[   45s] In file included from Dialog.cpp:15:
[   45s] GuiView.h:22:10: fatal error: QMainWindow: No such file or 
directory

[   45s]22 | #include 
[   45s]   |  ^
[   45s] compilation terminated.
[   45s] make[6]: *** [Makefile:1015: Dialog.o] Error 1
[   45s] make[6]: *** Waiting for unfinished jobs
[   45s] In file included from FindAndReplace.h:15,
[   45s]  from DialogFactory.cpp:14:
[   45s] DockView.h:17:10: fatal error: QDockWidget: No such file or 
directory

[   45s]17 | #include 
[   45s]   |  ^
[   45s] compilation terminated.
[   45s] make[6]: *** [Makefile:1015: DialogFactory.o] Error 1
[   45s] In file included from Action.cpp:14:
[   45s] GuiApplication.h:21:10: fatal error: QApplication: No such file 
or directory

[   45s]21 | #include 
[   45s]   |  ^~
[   45s] compilation terminated.

Those files that can't be found are present. I have also tried cmake and 
there the compilation succeeds. Exactly the same environment. It seems 
that in autoconf something is missing?


Everything is fine with Qt 5, BTW.

Regards,

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

Re: What is missing for LyX 2.4?

[Cor Blom]

Op 10-05-2023 om 11:36 schreef Pavel Sanda:

On Wed, May 10, 2023 at 11:13:52AM +0200, Cor Blom wrote:

On Wed, May 10, 2023 at 09:26:19AM +0200, Cor Blom wrote:

openSUSE does contain GM, but it applies a patch to disable some coders. I


Thanks for the info Cor.

I guess it's in your hands to add new dependencies for converters that
will serve as a workarounds for eps conversion - our only way left AFAICS.

Pavel


The workaround is to install ImageMagick-config-7-upstream and to remove
Imagemagick-config-7-SUSE.

If you move to GM, does this mean that IM will stop working?


No. But I don't think we are moving to GM because it apparatnetly won't solve
the problem once for all.

What I meant by workaround was to add e.g. pdftoppm (on debian part of 
poppler-utils)
to runtime dependencies of lyx package. In 2.4 we detect if IM is under ban - 
in that
case we try to add pdftoppm to converters so insetad of IM's eps->png we use
eps->pdf->png with help of pdftoppm (see bd0510b08). We need to look on PNG -> 
EPS
path yet.

No fiddling with packages on the side of user is necessary then.

Pavel


I understand. Thanks. I assume that information will be in the release 
notes, I will find it when I'll do the update to 2.4 and make sure to 
include the right dependencies.


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

Re: What is missing for LyX 2.4?

[Cor Blom]

Op 10-05-2023 om 10:46 schreef Pavel Sanda:

On Wed, May 10, 2023 at 09:26:19AM +0200, Cor Blom wrote:

openSUSE does contain GM, but it applies a patch to disable some coders. I


Thanks for the info Cor.

I guess it's in your hands to add new dependencies for converters that
will serve as a workarounds for eps conversion - our only way left AFAICS.

Pavel


The workaround is to install ImageMagick-config-7-upstream and to remove 
Imagemagick-config-7-SUSE.


If you move to GM, does this mean that IM will stop working?

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

Re: What is missing for LyX 2.4?

[Cor Blom]

Op 09-05-2023 om 21:38 schreef Pavel Sanda:

We need to check that opensuse (and fedora?) contain GM, and test it for some
time to see possible side effects.


openSUSE does contain GM, but it applies a patch to disable some coders. 
I don't see an easy way for users to get around that as there is with 
IM, where you can install the upstream config that has all the goods.


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

Re: Lyx is listed as proprietary software in gnome software

[Cor Blom]

Op 12-12-2022 om 21:36 schreef Lorenzo Bertini:

Hi list,

just a heads up that for some reason LyX is listed as having a 
proprietary license in gnome software. I don't know what is the cause. 
We might want to fix this soon. Any suggestions on who I can contact?




You give very little information. The licence provided by LyX is correct 
and it is the responsibility of distributions to make sure it is 
packaged with a correct reference to the licence. So, you need to 
contact the distribution and/or packager.


Cor

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

Re: #8577: Additional features manual

[Cor Blom]

Op 29-11-2022 om 12:35 schreef Pavel Sanda:

On Tue, Nov 29, 2022 at 10:11:42AM +, John Robert Hudson wrote:

On Monday, 28 November 2022 23:34:48 GMT Pavel Sanda wrote:

Excelent question. Are on Windows or Mac or Linux?

We did not freeze the fileformat for 2.4 yet so unless you can compile
the current development version we need to figure out how to deliver it
for people like you.

Perhaps Scott will propose soon some guidelines/deadlines when it comes to
release process so I have better answers when it's a good time to start
working on the documentation.

Pavel


I use openSUSE Linux but I assume that if I prepare the changes in 2.3 and
then open a text editor and copy and paste them into Additional.lyx, save that
and send you a patch, that should work. I am familiar with working with markup
languages and I do not think there will be anything in a 2.3 markup which will
be incompatible with 2.4 - at least not in the layout of Additional.lyx.

At least we could try that when I get round to sending my first patch and, if
it works, carry on that way until is is practical to have a stable version of
2.4.


Sounds possible, but the 2.4 manuals contain + ~5 years of changes so I would
think twice.

On the positive side, you are on Linux! Cor Blom who is our SUSE maintainer is
pretty active and as far as I can see there is repository with recent 2.4 so I
would try that:
https://build.opensuse.org/package/show/home%3Acornelisbb%3Alyx-unstable/lyx

(I have no clue whether how to install this on openSUSE though)
Pavel


And if that is not working, please let me know.

At the moment it replaces the present lyx installation (in my experience 
master is pretty stable). If a package that is co-installable is needed, 
I can change that.


Cor

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

Re: 2.4.0 plan for #12215 [LyX crashes with async processes (Qt6 only)] ?

[Cor Blom]

Op 14-11-2022 om 13:46 schreef Thibaut Cuvelier:
On Mon, 14 Nov 2022, 11:45 Pavel Sanda, > wrote:


On Fri, Nov 11, 2022 at 03:16:05PM -0500, Scott Kostyshak wrote:
 > If no one fixes it in time, shall we postpone 2.4.0

No, I wouldn't do that.

 > or proceed with 2.4.0 and state that Qt6 is not officially
supported because of #12215?

I see three options:
1) we don't support QT6 and break during ./configure if detected
2) we allow Qt6 with --enable-stdlib-debug
3) we allow Qt6 but forcing single thread only.

I don't have clear winner between these three.


I think that not supporting Qt 6 is the worst option, especially as it 
may create problems with package managers if they want to switch to Qt 6 
for any reason. Requiring a parameter to be set at configure time to 
allow Qt 6 acknowledging the potential problems would be acceptable, in 
my opinion.


As maintainer of the openSUSE packages I would like to be able to build 
with Qt6 when KDE Plasma 6 will be released.


https://community.kde.org/Schedules/Plasma_6

Cor



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

Re: Limit text width in the editor window (non-fullscreen mode)

[Cor Blom]

Op 24-10-2022 om 00:15 schreef Christopher Hillenbrand:

Dear LyX developers,

Here's a patch for adjusting editor text width in windowed mode (see
ticket https://www.lyx.org/trac/ticket/9376). It's an adaptation of
the previous patch uploaded by stwitt (two years ago). Please try it
out when you get a chance!

Since I couldn't access the true screen DPI from within
prefs2prefs.py, this patch removes the old settings \fullscreen_width
and \fullscreen_limit rather than hardcoding a default DPI value. But
if you think a different approach would be preferable, I'd be happy to
change it.

Best regards,
Christopher



I have tested it (thanks for doing this) and think it can be made a bit 
simpler, more useable. The possible units to measure the width are 
overwhelming. I counted 11 absolute options and 7 where percentages are 
used. Also when I change the unit, the number remains the same. It is 
not recalculated, which means the width can change very much.


Cor


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

approve link in wiki

[Cor Blom]

Hi,

I have updated the page on lyx on openSUSE:

https://wiki.lyx.org/LyX/LyXOnOpenSUSE

and added a link to where git snapshots packages can be found.

Can someone approve the link?

Thanks,

Cor

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

Re: Upgrade from buster to bullseye

[Cor Blom]

Op 08-11-2021 om 11:58 schreef Jean-Marc Lasgouttes:

Le 08/11/2021 à 11:20, Jean-Marc Lasgouttes a écrit :
However, when compiling the pdf of the UserGuide, none of the svgz 
icons could be converted, so the padf dispaly failed with a pdf image 
not found. Here is first of the error messages:


convert-im6.q16: attempt to perform an operation not allowed by the 
security policy `PDF' @ error/constitute.c/IsCoderAuthorized/421.

/usr/local/share/lyx-2.3.7dev/scripts/convertDefault.py ERROR
Execution of "convert" failed.


There is something I actually do not understand: this convert error 
triggers when converting a PDF file to something else. What is the path 
that created a pdf file from svg? Can we avoid it?


JMarc


The words "security policy" and "PDF" reminds me of a security policy in 
openSUSE, which disables imagemagick working with PS/PDF  by default. A 
additional package must be installed to enable this.


No idea if this is the same, but who knows...

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

Re: lyx in plasma sessions

[Cor Blom]

Op 09-08-2021 om 19:36 schreef paolo m.:

paolo m.  wrote:


I cannot preserve open lyx files through plama/kde sessions, is there a
way to obtain that?


I think you mean that when you have set in kde systemsetting to restore 
the previous session, that lyx is not restored while other apps are.


See:

https://www.reddit.com/r/kde/comments/ea3gfe/plasma_not_restoring_all_programs_from_previous/



Moreover all lyx files open as tabs of the first open file. I would like
to open lyx files in the current plasma activity file manager is in and
stay there through kde sessions. Is that possible?



In LyX "Preferences > Look and Feel > Document handling" you can set 
whether or not to open documents in tabs. You can tie LyX to Plasma 
activities, but that is more a Plasma question.


Regards,

Cor




thank you

pol





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

Re: DocBook to ePub

[Cor Blom]

Op 07-02-2021 om 23:21 schreef Thibaut Cuvelier:


BibTeX doesn't play a role to generate ePub: to generate the relevant 
DocBook tags, I rely on LyX' understanding of the .bib file (which 
typically works very well); the DocBook to ePub conversion seems to 
support references too.


For which documents do you have this problem?


I tested it on one of my own documents, that includes many references 
and they showed up as question marks in the epub. I cannot tell anything 
beyond this at the moment.


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

Re: DocBook to ePub

[Cor Blom]

Op 07-02-2021 om 14:35 schreef Pavel Sanda:

On Sun, Feb 07, 2021 at 02:09:03PM +0100, Cor Blom wrote:

2. There was mention of using system xslt and saxon, but I did not see any
configure options. Am I correct? BTW: I use autotools.


Not provided yet. What package versions of saxon and docbook xslt stylesheets
are now in suse repositories?

Pavel



Docbook-xsl: 1.79.2 in both supported versions (15.2 and Tumbleweed)
saxon6: 6.5.5, also in both versions.

Cor


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

Re: DocBook to ePub

[Cor Blom]

Op 29-01-2021 om 18:38 schreef Thibaut Cuvelier:
As promised, I started working on ePub output, building upon the new 
DocBook output.


I have build the latest git master on openSUSE and epub export is 
working fine.


I have two questions:

1. Bib(la)text references are ignored. Is that not possible, or for 
later, or does it need a configuration?


2. There was mention of using system xslt and saxon, but I did not see 
any configure options. Am I correct? BTW: I use autotools.


Thanks for all the work,

Cor

(openSUSE LyX maintainer)
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: display of $int...$ under QT5

[Cor Blom]

Op 02-09-2020 om 14:39 schreef Enrico Forestieri:

As regards where to put the fonts, you have the choice of leaving
them where they are installed by lyx (and, at least on debian, lyx
is able to find and use them), or package them separately and
register them with fontconfig. In this case, they can also be used
by other packages.

I really have no idea why it does not work for you.


My guess is: debian and fedora do not install texlive fonts in the 
default /usr/share/fonts directory. opensuse does. I can disable the 
texlive fonts and then all is working fine. If I don't there is a chance 
the wrong font is used.


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

Re: display of $int...$ under QT5

[Cor Blom]

Op 02-09-2020 om 11:45 schreef Enrico Forestieri:

On Wed, Sep 02, 2020 at 10:33:03AM +0200, Enrico Forestieri wrote:

[...]


This is to be expected, because the fonts should be seen only by lyx. This
is how QFontDatabase::addApplicationFont() should work. It is the fact that
you don't see some glyphs that indicates the failure.

However, it would be interesting if you could report the result of the
attached patch. This is a patch for lyx 2.3, the corresponding patch for
the development version 2.4 can be found as an attachment to another email
in this thread. It should show which font file lyx uses for math fonts.
You will have to configure lyx using LIBS=-lfontconfig, i.e.,

configure [your usual options here] LIBS=-lfontconfig

After building lyx, create a new document and then a math inset.
You should then see all used font files printed in the terminal.

If you do not add /usr/share/lyx/fonts to the fontconfig directories
(make sure that "fc-match -v 'esint10: style=lyx' | grep file:" does
not return the "correct" result) and no fonts in /usr/share/lyx/fonts
are spotted, we can be sure that QFontDatabase::addApplicationFont()
does not work.


I just checked it, and it works on debian. They package separately the
fonts in the package fonts-lyx. With this package installed, I get

$ fc-match -v "esint10: style=regular" | grep file:
file: "/usr/share/fonts/truetype/lyx/esint10.ttf"(w)

while, uninstalling it, I get

$ fc-match -v "esint10: style=regular" | grep file:
file: "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf"(w)

However, applying the above patch, without the fonts-lyx package I get

Filename: /usr/local/src/lyx/lyx-stable/lib/fonts/eufm10.ttf (family eufm10, 
style LyX)
Filename: /usr/local/src/lyx/lyx-stable/lib/fonts/cmsy10.ttf (family cmsy10, 
style LyX)
Filename: /usr/local/src/lyx/lyx-stable/lib/fonts/cmmi10.ttf (family cmmi10, 
style LyX)
Filename: /usr/local/src/lyx/lyx-stable/lib/fonts/cmr10.ttf (family cmr10, 
style LyX)
Filename: /usr/local/src/lyx/lyx-stable/lib/fonts/cmex10.ttf (family cmex10, 
style LyX)
Filename: /usr/local/src/lyx/lyx-stable/lib/fonts/msam10.ttf (family msam10, 
style LyX)
Filename: /usr/local/src/lyx/lyx-stable/lib/fonts/msbm10.ttf (family msbm10, 
style LyX)
Filename: /usr/local/src/lyx/lyx-stable/lib/fonts/wasy10.ttf (family wasy10, 
style LyX)
Filename: /usr/local/src/lyx/lyx-stable/lib/fonts/stmary10.ttf (family 
stmary10, style LyX)
Filename: /usr/local/src/lyx/lyx-stable/lib/fonts/esint10.ttf (family esint10, 
style LyX)

where /usr/local/src/lyx/lyx-stable is the lyx source dir.
Hence, QFontDatabase::addApplicationFont() works!

Reinstalling the fonts-lyx package I get

Filename: /usr/share/fonts/truetype/lyx/eufm10.ttf (family eufm10, style LyX)
Filename: /usr/share/fonts/truetype/lyx/cmsy10.ttf (family cmsy10, style LyX)
Filename: /usr/share/fonts/truetype/lyx/cmmi10.ttf (family cmmi10, style LyX)
Filename: /usr/share/fonts/truetype/lyx/cmr10.ttf (family cmr10, style LyX)
Filename: /usr/share/fonts/truetype/lyx/cmex10.ttf (family cmex10, style LyX)
Filename: /usr/share/fonts/truetype/lyx/msam10.ttf (family msam10, style LyX)
Filename: /usr/share/fonts/truetype/lyx/msbm10.ttf (family msbm10, style LyX)
Filename: /usr/share/fonts/truetype/lyx/wasy10.ttf (family wasy10, style LyX)
Filename: /usr/share/fonts/truetype/lyx/stmary10.ttf (family stmary10, style 
LyX)
Filename: /usr/share/fonts/truetype/lyx/esint10.ttf (family esint10, style LyX)

Meaning that the fonts of the fonts-lyx package take precedence.
However, all in all, it seems to work well on debian.
I don't know what the problem may be on other distros.



I get a compile error with your patch. I can give you the log, if  you 
want, but I do not have much time left to look further into this for 
now. Later this week maybe ...


I have tried moving the fonts to /usr/share/fonts, but then "lyx -dbg 
font" gives as result FAILED for the math fonts. And it did not solve 
the issue.


If this patch will be part of 2.4, is it then not an idea to change the 
default installation path of the lyx fonts to the default font 
directory? Important distros as fedora and debian are already doing this 
and it would my preference also.


Thanks,

Cor

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

Re: display of $int...$ under QT5

[Cor Blom]

Op 01-09-2020 om 22:21 schreef Enrico Forestieri:

We already have an elegant solution. We rely on Qt to do the right thing
with QFontDatabase::addApplicationFont(), but on linux it does not work
right, contrarily to Windows (and I think MacOS) where it works well.
In this case it should suffice to directly add the lyx font directory
to the fontconfig paths. The fonts ditributed with lyx are a superset
of the texlive ones and could also replace them. However, this is not
necessary because we can find our fonts by requesting the style "LyX",
provided that fontconfig can find them.


I think I know why it does not work. The lyx fonts are installed in 
/usr/share/lyx/fonts and it looks to me this is kind of hardcoded, 
because "lyx -dbg font" only gives OK for me when the fonts are in that 
directory.


Fontconfig, however, does not look into that directory. So "fc-match -v 
"esint10: style=lyx" | grep file:" only give me the correct result when 
the lyx fonts are in /usr/share/fonts.


When I add /usr/share/lyx/fonts to the directories where fontconfig 
looks, then it all works as it should. I can solve this by adding a 
fontconfig configuration file to the package.


Does this sound right to you?

Regards,

Cor

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

Re: display of $int...$ under QT5

[Cor Blom]

Op 01-09-2020 om 22:21 schreef Enrico Forestieri:

We already have an elegant solution. We rely on Qt to do the right thing
with QFontDatabase::addApplicationFont(), but on linux it does not work
right, contrarily to Windows (and I think MacOS) where it works well.
In this case it should suffice to directly add the lyx font directory
to the fontconfig paths. The fonts ditributed with lyx are a superset
of the texlive ones and could also replace them. However, this is not
necessary because we can find our fonts by requesting the style "LyX",
provided that fontconfig can find them.


This rings a bell. I'm going to check on something and report back later.

Cor

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

Re: display of $int...$ under QT5

[Cor Blom]

Op 01-09-2020 om 21:03 schreef Pavel Sanda:

On Tue, Sep 01, 2020 at 07:56:43PM +0200, Cor Blom wrote:

I have some additional information on top of my previous response with the
screenshots. When I leave the tex fonts enabled and I link the lyx fonts
into /usr/share/fonts in the folder lyx, nothing changes, but if I name the
link zlyx I have the same result as without texfonts. It seems the fonts are
read alphabetically and the last result is used.

I hope I make sense.


Makes sense. Is this 'zlyx' solution acceptable hack from the opensuse packaging
point of view?

Another option would be to patch the sources for packaging and rename 
esint10.ttf
to e.g. lyxesint10.tff as well as all occurences of esint in the code (most 
important
would be symbols file).

Yet another option would be that we do this upstream, I am not sure how good 
idea
is it though.

Maybe there is also some more elegant solution to change the way lyx picks
the font (I'm not sure if its fontconfig or lyx influences that decision) - 
don't
know this part of the code well and don't have your setup to debug it.


I am prepared to do some hacks to make this work. User experience is 
important. I need to think about the best solution packaging wise.


But I would prefer an upstream solution. Sorry I cannot help you with 
this, my coding skills are very limited.


Cor




Pavel


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

Re: display of $int...$ under QT5

[Cor Blom]

Op 01-09-2020 om 21:03 schreef Pavel Sanda:

On Tue, Sep 01, 2020 at 07:36:35PM +0200, Cor Blom wrote:

I have made two screenshots, one with the fonts from texlive enabled
(with-texfonts) and the other disabled (without-texfonts through fontconfig.


Unfortunately this is somewhat older test file, I would like to check that
limits around \int are correctly placed as well.
Could you check whether
\int \1 ^2
puts the 1 and 2 after the integral sign?


Yes.



  

I see a clear difference and it seems the result is better when I have
disable the fonts from texlive. I cannot change the default system setting
on openSUSE, though: texfonts will be available by default.


Just double checking, the opensuse default is texlive fonts enabled, right?


Yes. For quite a number of years now. They are installed in 
/usr/share/fonts/


Cor



Pavel


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

Re: display of $int...$ under QT5

[Cor Blom]

Op 01-09-2020 om 18:13 schreef Pavel Sanda:

On Tue, Sep 01, 2020 at 05:46:10PM +0200, Cor Blom wrote:

As far as I can see the esint fonts are
working nicely in LyX.


Hi Cor, would you mind posting your screenshot of
lib/fonts/test/check_glyphs.lyx
with Tools>Preferences>Display>Instant preview off?

Pavel



I have some additional information on top of my previous response with 
the screenshots. When I leave the tex fonts enabled and I link the lyx 
fonts into /usr/share/fonts in the folder lyx, nothing changes, but if I 
name the link zlyx I have the same result as without texfonts. It seems 
the fonts are read alphabetically and the last result is used.


I hope I make sense.

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

Re: display of $int...$ under QT5

[Cor Blom]

Hi Pavel,

Op 01-09-2020 om 18:13 schreef Pavel Sanda:

On Tue, Sep 01, 2020 at 05:46:10PM +0200, Cor Blom wrote:

As far as I can see the esint fonts are
working nicely in LyX.


Hi Cor, would you mind posting your screenshot of
lib/fonts/test/check_glyphs.lyx
with Tools>Preferences>Display>Instant preview off?

Pavel



I have made two screenshots, one with the fonts from texlive enabled 
(with-texfonts) and the other disabled (without-texfonts through fontconfig.


This is on openSUSE Tumbelweed with Qt 5.15 and texlive 2020 with latest 
lyx-git compiled in the same way as the official openSUSE rpm.


I can text also on openSUSE Leap 15.2 with Qt 5.12 and texlive 2017,

I see a clear difference and it seems the result is better when I have 
disable the fonts from texlive. I cannot change the default system 
setting on openSUSE, though: texfonts will be available by default.


I hope this helps.

For others interested: the rpms can be found here:

https://download.opensuse.org/repositories/home:/cornelisbb:/lyx-unstable/openSUSE_Tumbleweed/

(although it may take some time before they're published there).

Regards,

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

Re: display of $int...$ under QT5

[Cor Blom]

Sorry to jump very late in this threat, only saw it today.

I don't use LyX for math, so that part I don't know anything about, but 
I use openSUSE and maintain LyX there, so I am interested to get this right.


By default I disable all texlive fonts for the UI by linking the 
58-texlive-* config files in /etc/fonts/avail.d to /etc/fonts/conf.d (on 
openSUSE Tumbleweed the first directory is now in 
/usr/share/fontconfig/avail.d). As far as I can see the esint fonts are 
working nicely in LyX. Enabling those fonts by removing those 
58-texlive-* files again by removing them from /etc/fonts/conf.d has the 
result that I see what Bernhart saw, I think.


If the cause is how LyX is packaged in openSUSE, please file a bug in 
the openSUSE bugzilla. If it's mentioned here, the chance is I'll miss it.


BTW: the LyX fonts are packaged in /usr/share/lyx/fonts and not linked 
in any way to /usr/share/fonts.


Thanks,

Cor

Op 25-08-2020 om 11:22 schreef M.B. Schiekel:

Am 24.08.20 um 18:02 schrieb Jean-Marc Lasgouttes:

After a longer discussion here I found, that the cause of this problem
was the interaction of LyX with QT5-Qt-5.9.4. Then I compiled LyX with
QT4 and this workaround was fine for me.
Now with LyX 2.3.5.2 there is the same problem with QT5-5.12.7 and again

...
Unfortunately, it is not my failing memory that prevented from fixing
the bug. Since I cannot reproduce it, it is difficult for me to do
something about it.

Let's start by a shot in the dark: does it make a difference to set the
environment variable QT_HARFBUZZ to "old" ?

Even if it does, I suspect it will not be enough for a long-term fix.

Did I understand correctly that you can compile LyX? Does it mean that
you can try a patch too? A possibility is that Qt does not like (ass
Pavel noted) to have a font with a character at position 1 (which is
where \int lives in esint10 font). We would have to duplicate the
character somewhere else in the font.
...



Hi Jean-Marc,

thank you for your kind reply. This morning I tried to compile LyX
2.3.5.2 with your suggested environment-variable
   export QT_HARFBUZZ=old ,
and yes, it works, all integral-signs are Ok.


Did I understand correctly that you can compile LyX? Does it mean that
you can try a patch too?

Well, I can compile LyX. Concerning an patch I can try - depends if this
patch will automatically change the sources, because I don't want to
make changes in the sources by hand :-)

So far, so good. And many thanks for all your wonderful LyX-work!
bernhard



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

Re: bug with import of document with multiple languages

[Cor Blom]

Op 25-05-2020 om 20:01 schreef Richard Kimberly Heck:


Certainly sounds like a bug. Can you file a report please?

Riki



Bug #11878


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

bug with import of document with multiple languages

[Cor Blom]

Hi,

Take the following, simple document:

\documentclass[ngerman,british]{scrbook}
\usepackage{fontspec}
\usepackage{polyglossia}
\setdefaultlanguage[variant=british]{english}
\setotherlanguage{german}

\begin{document}

English

\begin{german}

Deutsch

\end{german}

Continue

\end{document}

When I import this document in LyX after the german part the document in 
Lyx does not switch back to the default language, but it stays German. I 
expect that after "\end{german}" the default language would be used.


Do I something wrong? Or is this a bug?

This is the latest version: 2.3.3.4 on openSUSE.

Thanks,

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

Re: RTL cursor movement

[Cor Blom]

Op 23-07-19 om 07:41 schreef Jürgen Spitzmüller:

Am Dienstag, den 23.07.2019, 06:40 +0200 schrieb Jürgen Spitzmüller:

I see. This makes sense. I will update the docs.


This is what I came up with:

Right-to-left cursor movement: Here you can define how cursor movement
(with the arrow keys) behaves when writing scripts with right-to-left
direction (e.g., Arabic, Hebrew or Farsi).

Logical means that the cursor follows the logic of the text direction,
and the arrows’ direction relates to the directionality of the main
paragraph language. E. g., in embedded right-to-left text in a left-to-
right paragraph (say, Hebrew embedded in English), the cursor starts at
the right (that is, at the beginning of the embedded passage in the
right-to-left logic) when coming from the left. The meaning of the key
is thus swapped for that part; right arrow in this specific case always
means: move forward in text (even if this means: move left). This
setting might be useful in texts that mix left-to-right and right-to-
left scripts, since the cursor then follows a coherent “text logic”.

Visual means: always move to the direction towards which the arrows
really point. In this case, in embedded right-to-left text in a left-
to-right paragraph, the cursor starts at the left (in the text logic:
from the end) when coming from the left. The visual meaning of the key
is thus maintained in all cases, at the expense of the text logic.

Jürgen



Looks good. You have worded it better than I did. Thanks.

Cor

Re: RTL cursor movement

[Cor Blom]

Op 22-07-19 om 20:06 schreef Jean-Marc Lasgouttes:

We could also wonder whether anybody misses the logical navigation...


I use logical navigation. What I expect is that with logical navigation 
the direction is determined by the direction (RTL or LTR) of the whole 
paragraph. When in the paragraph a few words have an alternative 
direction (such as a couple of RTL words in LTR text) than with those 
words the cursor movement is going backwards, following the direction of 
the text, but also following the logic of what is forwards and backwards 
of the surrounding text.


With visual navigation the cursor always follows the direction of the 
main direction of the paragraph, ignoring words that have a different 
direction.


This is how is works for me in 2.3.3.

Cor

Re: [LyX/master] Respect OS-level keyboard language

[Cor Blom]

Op 20-07-19 om 13:34 schreef Jean-Marc Lasgouttes:
To be clear, this feature is mainly a request of Hebrew writers, as I 
see it.


As someone writing stuff in multiple western languages and Hebrew I 
welcome this change, but I think it is overdone. My keyboard setup is 
that I use a different keyboard per script, not per language. I type all 
western language with a US keyboard with composite key enabled. I cannot 
type a different script with that keyboard layout, so for that I switch 
keyboard and in that case only I would like LyX to follow that change by 
changing the language. I think LyX needs to do what LibreOffice does and 
have some setting per script: Latin, RTL and Asian. For each script a 
default language can be set and the rest can be changed through LyX as 
it is now. I find changing keyboard cumbersome and confusing, so I 
prefer to do it as little as possible.


That is at least how I work.

Thanks for looking into this,

Cor

Re: ImageMagick security settings in openSUSE

[Cor Blom]

Op 10-07-19 om 16:51 schreef Pavel Sanda:

I'm not sure for how big percentage of userbase I speak of but to butcher
postscript processing renders lyx quite unusable imho, so question is to
whether suse wants lyx in its repositories at all if this does not work...
So if it was on me would rather ask for removing lyx from your official
repos and let only advanced users to fetch from alternative sources and
tweak settings -- because delivering half non functional lyx just give
us bad reputation.
But again, that's due to my way of using lyx, don't take this as official
lyx team stand point:)


Personally I use LyX with openSUSE's hardened ImageMagick without any 
problems. I would not have noticed the issue with ImageMagick had it not 
been reported as a bug.


I am not really afraid for the reputation of LyX. I think users who are 
confronted by this will blame (open)SUSE (or understand it). In the 
meantime I try to spread the information in different, relevant places, 
so that it can hopefully be found.


Thanks for your input.

Cor

Re: ImageMagick security settings in openSUSE

[Cor Blom]

Op 10-07-19 om 16:51 schreef Pavel Sanda:

Can't you simply demand this 'alternative configuration' as dependency when
lyx is installed?


I can try this. The reason for this security policy has been explained 
to me, so I have little hope. But who knows...


I have updated the wiki with the relevant information:

https://wiki.lyx.org/LyX/LyXOnOpenSUSE

It need the confirmation of a link.

Thanks,

Cor

Re: ImageMagick security settings in openSUSE

[Cor Blom]

Op 10-07-19 om 15:30 schreef Pavel Sanda:

On Wed, Jul 03, 2019 at 03:43:06PM +0200, Cor Blom wrote:

Dear LyX devs,

Because of the following bug

https://bugzilla.opensuse.org/show_bug.cgi?id=1139928

I have become aware of the strict security settings in openSUSE which
limits capabilities of ImageMagick. There is an alternative setting that
the user can activate, but most users will not know this.


Is this security measure sideeffect of ghostscript problems from last september?

As far as I understood the total ban of conversions was just temporary measure
which should be lifted once the individual CVEs were resolved. I believe both
upstream and other distros already lifted it.


I am just writing this, so you are aware of this. I don't know a solution.


In decreasing order:
- Can't you just file suse-related bug to remove the ban?
- Can't you pull/set different IM config iff lyx is installed?
- Can't you trigger some message if lyx is installed so user is at least know
   how to fix it.

If nothing of this work, we could add some note to our release notes
that users of open suse need to fix IM settings.

Pavel



The following message describes the situation for openSUSE Leap 15.0, 
but it is also true for 15.1 and Tumbleweed:


https://lists.opensuse.org/opensuse-security-announce/2019-05/msg00010.html

In short: the user can install an alternative configuration for IM that 
enables postscript related stuff (and other things), following upstream 
IM setting. The default SUSE setting are very strict.


I have added a README.SUSE to the package and refer to that in the 
description that explains the situation and tells the user the options 
he has. It has been discussed on the openSUSE Factory mailinglist, but 
the suggestion how to inform users is what I have done. See:


https://build.opensuse.org/request/show/713564

I came accross this because a bug was filed that eps preview was not 
working. This is not really my area of expertise. As far as I can see, 
the situation in (open)SUSE will remain as it is. This means the user 
either installs an alternative configuration for ImageMagick, or edits 
security pollicy settings for IM manually.


In general postscript does not work out of the box on openSUSE for 
security reasons nowadays, but the user can enable this by installing 
additional packages.


I hope this give enough information. There is not much more that can be 
done. Maybe this information can be added to the LyX wiki also?


Kind regards,

Cor

ImageMagick security settings in openSUSE

[Cor Blom]

Dear LyX devs,

Because of the following bug

https://bugzilla.opensuse.org/show_bug.cgi?id=1139928

I have become aware of the strict security settings in openSUSE which 
limits capabilities of ImageMagick. There is an alternative setting that 
the user can activate, but most users will not know this.


I am just writing this, so you are aware of this. I don't know a solution.

Regards,

Cor

rpmlint report for lyx on opensuse

[Cor Blom]

LyX 2.3.1 builds fine on openSUSE.

Maybe you are interested in warnings and errors that the buildsystem
used by openSUSE report:

[ 1130s] RPMLINT report:
[ 1130s] ===
[ 1139s] lyx.x86_64: W: empty-%post
[ 1139s] lyx.x86_64: W: empty-%postun
[ 1139s] lyx.x86_64: W: non-executable-script
/usr/share/lyx/lyx2lyx/profiling.py 644 /usr/bin/env python
[ 1139s] lyx.x86_64: W: non-executable-script
/usr/share/lyx/scripts/prefTest.pl.in 644 /usr/bin/env perl
[ 1139s] This text file contains a shebang or is located in a path dedicated for
[ 1139s] executables, but lacks the executable bits and cannot thus be
executed.  If
[ 1139s] the file is meant to be an executable script, add the executable bits,
[ 1139s] otherwise remove the shebang or move the file elsewhere.
[ 1139s]
[ 1139s] lyx.x86_64: W: position-independent-executable-suggested /usr/bin/lyx
[ 1139s] lyx.x86_64: W: position-independent-executable-suggested
/usr/bin/lyxclient
[ 1139s] lyx.x86_64: W: position-independent-executable-suggested
/usr/bin/tex2lyx
[ 1139s] This executable should be position independent (all binaries
should).  Check
[ 1139s] that it is built with -fPIE/-fpie in compiler flags and -pie
in linker flags.
[ 1139s]
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/TeXFiles.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/clean_dvi.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/convertDefault.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/convert_pdf.py
[ 1139s] lyx.x86_64: W: script-without-shebang /usr/share/lyx/scripts/csv2lyx.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/ext_copy.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/fen2ascii.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/fig2pdftex.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/fig2pstex.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/fig_copy.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/html2latexwrapper.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/include_bib.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/layout2layout.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/legacy_lyxpreview2ppm.py
[ 1139s] lyx.x86_64: W: script-without-shebang /usr/share/lyx/scripts/lyxpak.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/lyxpreview2bitmap.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/lyxpreview_tools.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/prefs2prefs.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/prefs2prefs_lfuns.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/prefs2prefs_prefs.py
[ 1139s] lyx.x86_64: W: script-without-shebang
/usr/share/lyx/scripts/tex_copy.py
[ 1139s] This text file has executable bits set or is located in a
path dedicated for
[ 1139s] executables, but lacks a shebang and cannot thus be executed.
If the file is
[ 1140s] meant to be an executable script, add the shebang, otherwise remove the
[ 1140s] executable bits or move the file elsewhere.
[ 1140s]
[ 1140s] lyx.x86_64: W: suse-filelist-forbidden-bashcomp-userdirs
/etc/bash_completion.d/lyx is not allowed in SUSE
[ 1140s] This directory is for user files,   use
/usr/share/bash-
[ 1140s] completion/completions/
[ 1140s]
[ 1140s] lyx.x86_64: E: env-script-interpreter (Badness: 9)
/usr/share/lyx/configure.py /usr/bin/env python
[ 1140s] lyx.x86_64: E: env-script-interpreter (Badness: 9)
/usr/share/lyx/lyx2lyx/lyx2lyx /usr/bin/env python
[ 1140s] lyx.x86_64: E: env-script-interpreter (Badness: 9)
/usr/share/lyx/scripts/listerrors /usr/bin/env python
[ 1140s] lyx.x86_64: E: env-script-interpreter (Badness: 9)
/usr/share/lyx/scripts/svg2pdftex.py /usr/bin/env python
[ 1140s] lyx.x86_64: E: env-script-interpreter (Badness: 9)
/usr/share/lyx/scripts/svg2pstex.py /usr/bin/env python
[ 1140s] This script uses 'env' as an interpreter. For the rpm runtime
dependency
[ 1140s] detection to work, the shebang #!/usr/bin/env python  needs
to be patched into
[ 1140s] #!/usr/bin/python  otherwise the package dependency generator
merely adds a
[ 1140s] dependency on /usr/bin/env rather than the actual interpreter
/usr/bin/python.
[ 1140s] Alternatively, if the file should not be executed, then
ensure that it is not
[ 1140s] marked as executable or don't install it in a path that is reserved for
[ 1140s] executables.

Re: cmake and boost

[Cor Blom]

Op 27-07-17 om 22:27 schreef Kornel Benko:

This means that the devel version boost-regex is not found. But maybe your 
installed cmake
is not able to find such new boost version. Checking FindBoost.cmake in cmake 
3.9, the last
known boost are versions between 1.63.00 .. 1.64.99 though.
So, what is your cmake version?


openSUSE Tumbleweed has version 3.8.2.



OTOH, why use boost-regex? You have gcc7.1 installed, so you already may use 
std-regex (e.g. without boost)


Only recently openSUSE has split the boost-devel package in separate 
packages. I still use boost-devel, which means all boost-devel packages 
are installed. I haven't come around to changing this yet.


Does it mean that with gcc7.1 lyx can be build without boost?



Nonetheless, you found a bug in our cmake files.

You may want to try the attached.


Wit the latest git this bug is gone and lyx builds fine.

Thanks.

Re: cmake and boost

[Cor Blom]

Op 27-07-17 om 20:11 schreef Kornel Benko:

Have you requested LYX_USE_STD_REGEX?


How do I do that?

If yes, do you have the devel package for boost-regex installed?

Don't know the package name for SuSE, on ubuntu it is for example
libboost-regex1.55-dev


I have those packages installed. They are called on Tumbleweed:

- libboost_regex1_64_0
- libboost_regex1_64_0-devel

This is the last part of the log:

[   91s] -- Building in-source
[   91s] -- The C compiler identification is GNU 7.1.1
[   91s] -- The CXX compiler identification is GNU 7.1.1
[   91s] -- Check for working C compiler: /usr/bin/cc
[   91s] -- Check for working C compiler: /usr/bin/cc -- works
[   91s] -- Detecting C compiler ABI info
[   91s] -- Detecting C compiler ABI info - done
[   91s] -- Detecting C compile features
[   91s] -- Detecting C compile features - done
[   91s] -- Check for working CXX compiler: /usr/bin/c++
[   92s] -- Check for working CXX compiler: /usr/bin/c++ -- works
[   92s] -- Detecting CXX compiler ABI info
[   92s] -- Detecting CXX compiler ABI info - done
[   92s] -- Detecting CXX compile features
[   92s] -- Detecting CXX compile features - done
[   92s] --
[   92s] -- CXX11_FLAG_DETECTED = "--std=c++14"
[   96s] -- Compiler supports std_regex
[   96s] -- Found CXX11Compiler: --std=c++14
[   96s] -- Using GCC version 7
[   96s] -- CMAKE_COMPILER_IS_GNUCXX = 1
[   96s] -- CMAKE_CXX_STANDARD set to 14
[   96s] -- Found Qt-Version 5.9.1
[   96s] -- Looking for magic_file
[   96s] -- Looking for magic_file - not found
[   96s] -- Function magic_file not found
[   96s] -- Looking for magic_open
[   96s] -- Looking for magic_open - not found
[   96s] -- Function magic_open not found
[   96s] -- Looking for magic_load
[   97s] -- Looking for magic_load - not found
[   97s] -- Function magic_load not found
[   97s] -- Looking for magic_close
[   97s] -- Looking for magic_close - not found
[   97s] -- Function magic_close not found
[   97s] -- Looking for magic_error
[   97s] -- Looking for magic_error - not found
[   97s] -- Function magic_error not found
[   97s] -- Could NOT find Magic (missing:  Magic_INCLUDE_DIR 
Magic_LIBRARY HAS_MAGIC_FUNCTIONS)
[   97s] -- Could NOT find MYTHESLIB (missing:  MYTHESLIB_LIBRARY 
MYTHESLIB_INCLUDE_DIR)
[   97s] -- Could NOT find ASPELL (missing:  ASPELL_LIBRARY 
ASPELL_INCLUDE_DIR)

[   97s] -- ASPELL not found, building without ASPELL support
[   97s] -- Found ENCHANT: /usr/lib64/libenchant.so
[   97s] -- Building with USE_ENCHANT
[   97s] -- Found HUNSPELL: /usr/lib64/libhunspell.so
[   97s] -- Building with USE_HUNSPELL
[   97s] -- Found PythonInterp: /usr/bin/python2 (found suitable version 
"2.7.13", minimum required is "2.0")

[   97s] -- Could NOT find LYX_PY_polib (missing:  LYX_PY_POLIB)
[   97s] -- You will be unable to update layouttranslations file
[   97s] -- Looking for iconv
[   97s] -- Looking for iconv - found
[   97s] -- Found iconv library:
[   97s] -- Found Z: /usr/lib64/libz.so
[   97s] -- Searching for boost
[   97s] CMake Error at CMakeLists.txt:814 (message):
[   97s]   Boost not found

Cor

cmake and boost

[Cor Blom]

Hi,

I'm testing 2.3 snapshots for openSUSE packaging and stumbled on a 
problem when building with cmake and system-boost. On Tumbleweed 
system-boost is not found and only there this error occurs. On Leap 42.2 
and 42.3 there is no error, and also not when building with autotools. 
With automake there is also no error on Tumbleweed.


All logs can be found here[1], but as far as I can see they don't tell much.

Cor

[1] https://build.opensuse.org/project/show/home:cornelisbb:lyx-unstable

Re: cmake and make install

[Cor Blom]

Op 25-07-17 om 20:49 schreef Scott Kostyshak:

On Fri, Jun 02, 2017 at 09:55:33AM +0200, Cor Blom wrote:

Op 01-06-17 om 12:34 schreef Kornel Benko:

(the "%cmake"  macro inheritis all kind of openSUSE settings).

Which ones?

Expanded it becomes this:

find . -name CMakeLists.txt -exec sed -i -re
'/^[[:blank:]]*[sS][eE][tT][[:blank:]]*\([[:blank:]]*(CMAKE_BUILD_TYPE|CMAKE_COLOR_MAKEFILE|CMAKE_INSTALL_PREFIX|CMAKE_VERBOSE_MAKEFILE).*\)/{s/^/#IGNORE
/}' '{}' +

Outch. What went wrong if not using this command?
I AM interested.
Specifically
CMAKE_VERBOSE_MAKEFILE will be reset with -DLYX_QUIET=ON
CMAKE_INSTALL_PREFIX will be set on the commandline



If I don't use openSUSE's preconfigured settings for cmake but define them
myself, the make install stage is running fine. Made me wonder why I didn't
do that in the first place. Thanks for the help.

Will later look into other suggestions made.


Cor, so the default call to CMake does work for you in the end?
I just want to check if there is anything we need to improve on our end.

Scott



Yes, as far as I can see it works fine. I've set up building regular 
snapshots on openSUSE [1] and it seems ok. Since then I have not looked 
into it a lot. I need to do that during the coming weeks, because I 
seriously consider switching the openSUSE packages (of which I am the 
maintainer) to cmake.


Thanks,

Cor

[1] https://build.opensuse.org/package/show/home:cornelisbb:lyx-unstable/lyx

fonts provided by lyx

[Cor Blom]

Hi,

According to "ReadmeBaKoMa4LyX.txt" and "BaKoMaFontLicense.txt" in the 
lib/fonts directory the included fonts are meant for Windows. Does this 
mean they are not necessary for linux?


Thanks,

Cor

Re: cmake and make install

[Cor Blom]

Op 01-06-17 om 12:34 schreef Kornel Benko:

(the "%cmake"  macro inheritis all kind of openSUSE settings).

Which ones?

Expanded it becomes this:

find . -name CMakeLists.txt -exec sed -i -re
'/^[[:blank:]]*[sS][eE][tT][[:blank:]]*\([[:blank:]]*(CMAKE_BUILD_TYPE|CMAKE_COLOR_MAKEFILE|CMAKE_INSTALL_PREFIX|CMAKE_VERBOSE_MAKEFILE).*\)/{s/^/#IGNORE
/}' '{}' +

Outch. What went wrong if not using this command?
I AM interested.
Specifically
CMAKE_VERBOSE_MAKEFILE will be reset with -DLYX_QUIET=ON
CMAKE_INSTALL_PREFIX will be set on the commandline



If I don't use openSUSE's preconfigured settings for cmake but define 
them myself, the make install stage is running fine. Made me wonder why 
I didn't do that in the first place. Thanks for the help.


Will later look into other suggestions made.

Cor

Re: cmake and make install

[Cor Blom]

Op 01-06-17 om 09:57 schreef Kornel Benko:

Am Donnerstag, 1. Juni 2017 um 08:56:06, schrieb Cor Blom <corne...@solcon.nl>

What is this BuildService about?


This buildservice is used to build the openSUSE distribution. It's like 
Ubuntu's PPA. I want to see if cmake is a usuable alternative for 
building the lyx package for openSUSE. I am the maintainer of the 
official package in the distro. And I like a challenge.




make


Here it should be
'make package'


If I understand correctly this is for creating a package on a local 
computer, but not usable for distribution packaging.





make install


Here: sudo rpm -U lyx23-2.3.0-something.rpm


(the "%cmake"  macro inheritis all kind of openSUSE settings).


Which ones?


Expanded it becomes this:

find . -name CMakeLists.txt -exec sed -i -re 
'/^[[:blank:]]*[sS][eE][tT][[:blank:]]*\([[:blank:]]*(CMAKE_BUILD_TYPE|CMAKE_COLOR_MAKEFILE|CMAKE_INSTALL_PREFIX|CMAKE_VERBOSE_MAKEFILE).*\)/{s/^/#IGNORE 
/}' '{}' +

mkdir -p build
cd build
/usr/bin/cmake .. '-GUnix Makefiles' -DCMAKE_INSTALL_PREFIX:PATH=/usr 
-DINCLUDE_INSTALL_DIR:PATH=/usr/include 
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
-DSHARE_INSTALL_PREFIX:PATH=/usr/share 
-DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 -DCMAKE_BUILD_TYPE=RelWithDebInfo 
'-DCMAKE_C_FLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 -Wall 
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -DNDEBUG' 
'-DCMAKE_CXX_FLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 -Wall 
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -DNDEBUG' 
'-DCMAKE_Fortran_FLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -DNDEBUG' 
'-DCMAKE_EXE_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' 
'-DCMAKE_MODULE_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined 
-Wl,-z,now' '-DCMAKE_SHARED_LINKER_FLAGS=-Wl,--as-needed 
-Wl,--no-undefined -Wl,-z,now' -DLIB_SUFFIX=64 
-DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
-DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF 
-DCMAKE_COLOR_MAKEFILE:BOOL=OFF -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF 
-DCMAKE_MODULES_INSTALL_DIR=/usr/share/cmake/Modules -DLYX_INSTALL=ON 
-DLYX_USE_QT=QT5 -DLYX_EXTERNAL_BOOST=OFF -DLYX_PROGRAM_SUFFIX=ON 
-DLYX_ASPELL=OFF -DLYX_HUNSPELL=ON -DLYX_ENCHANT=ON





I'm stuck with the "make install" part. The first two steps are running
fine. I get the following error:

make: *** No rule to make target 'install'.  Stop.


That is surprising. What is the output of 'make help'? It should be the list
of all targets.
Here it is:
#make help|grep install
... install/local
... install/strip
... list_install_components
... install



As I don't build locally I don't have access to "make help". I will look 
into that later, when I've more time. (I'm not in a hurry to solve this).


Thanks for the help,

Cor

cmake and make install

[Cor Blom]

Hi,

I'm experimenting with building lyx (2.3 git) with cmake in the openSUSE 
BuildService. I'm using the following commands:


%cmake \
-DLYX_INSTALL=ON \
-DLYX_USE_QT=QT5 \
-DLYX_EXTERNAL_BOOST=OFF \
-DLYX_PROGRAM_SUFFIX=ON \
-DLYX_ASPELL=OFF \
-DLYX_HUNSPELL=ON \
-DLYX_ENCHANT=ON

make

make install

(the "%cmake"  macro inheritis all kind of openSUSE settings).

I'm stuck with the "make install" part. The first two steps are running 
fine. I get the following error:


make: *** No rule to make target 'install'.  Stop.

Is there a solution?

Thanks,

Cor

P.S.: my experimenting can be found here:

https://build.opensuse.org/package/show/home:cornelisbb:lyx-unstable/lyx-qt5

Re: cmake on linux

[Cor Blom]

Op 22-05-17 om 11:02 schreef Kornel Benko:

I am using it on linux all the time without problems.
Do you have questions about how to compile and create a package (debian or rpm)?


Thanks, I'll try that then. openSUSE is rpm. I saw there is an 
INSTALL.cmake, so I'll go from there. I think I'll manage.


Cor

cmake on linux

[Cor Blom]

Hi,

Coming lyx 2.3 requires automake 1.14, but openSUSE Leap only provides 
1.13. Now 2.3 will come too late to 42.3 (which is scheduled for July), 
so for the official distribution it will not be a problem, but I would 
still  like to provide 2.3  for Leap 42.3 in the future in an addon 
repository. From the commit log I understand there is a good reason to 
go with automake 1.14, so my question is: is using cmake a good option? 
I know it is used for the Windows binary, but is it also in a good state 
for linux?


Thanks,

Cor

Re: [ANNOUNCE] LyX 2.2.3 Released

[Cor Blom]

Op 16-05-17 om 04:45 schreef Nandor Sieben:

The source files for 2.2.3 seem to be missing.


Yes, they seem not to be copied to ftp://ftp.lyx.org/pub/lyx/stable/2.2.x/

Can this be corrected? Thanks,

Cor

Re: LyX and (ancient) Hebrew

[Cor Blom]

Op 03-12-16 om 22:51 schreef Scott Kostyshak:

The other thing is that on screen, when I type a rtl text in a ltr
documents, I have to mark that word as e.g. Hebrew before the sequence is
right. I would be nice to have that done automatically. Xetex does it right,
even if it is not marked as rtl. What would be great is an option to set not
only a default rtl font, but also a default rtl language, that is set
automatically by lyx in the document when rtl text is entered (and in Hebrew
Lyx of course vice versa).



I don't understand, but that's probably because I know nothing about
RTL or fonts. You might want to make a trac ticket for this and describe
the feature in more detail. I'm guessing setting the component of the
ticket to "bidi" is best.


Ticket #10514

Re: LyX and (ancient) Hebrew

[Cor Blom]

Op 03-12-16 om 23:03 schreef Cor Blom:

Op 03-12-16 om 22:51 schreef Scott Kostyshak:

The fonts are the issue, both screenfonts and document fonts. Lyx
allows for
both to set only one font and many fonts do not support rtl languages
properly. I think what LibreOffice does (and I think Ms Office does the
same) is a way to go: add a separate font setting for RTL languages,
both
for screen font as for the document font.

Ah interesting idea. Where does LibreOffice do this? Attached is a
screenshot of my LO font settings. Is the option there or somewhere
else?


It is under language settings. See attached screenshot.


And if the options to rtl is activated in the format dialogues it 
becomes possible to set separate rtl fonts. E.g. under "Default fonts" 
under "libreOffice Writer", but also in other places where fonts can be set.


Cor

Re: LyX and (ancient) Hebrew

[Cor Blom]

Op 03-12-16 om 22:51 schreef Scott Kostyshak:

The fonts are the issue, both screenfonts and document fonts. Lyx allows for
both to set only one font and many fonts do not support rtl languages
properly. I think what LibreOffice does (and I think Ms Office does the
same) is a way to go: add a separate font setting for RTL languages, both
for screen font as for the document font.

Ah interesting idea. Where does LibreOffice do this? Attached is a
screenshot of my LO font settings. Is the option there or somewhere
else?


It is under language settings. See attached screenshot.




The other thing is that on screen, when I type a rtl text in a ltr
documents, I have to mark that word as e.g. Hebrew before the sequence is
right. I would be nice to have that done automatically. Xetex does it right,
even if it is not marked as rtl. What would be great is an option to set not
only a default rtl font, but also a default rtl language, that is set
automatically by lyx in the document when rtl text is entered (and in Hebrew
Lyx of course vice versa).

I don't understand, but that's probably because I know nothing about
RTL or fonts. You might want to make a trac ticket for this and describe
the feature in more detail. I'm guessing setting the component of the
ticket to "bidi" is best.


Don't have time for that at the moment, but can do that somewhere in the 
coming week.


Thanks,

Cor

Re: LyX and (ancient) Hebrew

[Cor Blom]

Op 03-12-16 om 22:24 schreef mn:

Where can the polyglossia option be set?
This is not obvious to me.
Under doc-settings>language>language package>custom = polyglossia ?


Yes, I have to admit: this is not obvious. The setting "automatic" works 
for me, it give me polyglossia (although it is not explicitly 
mentioned). It can also be set under general lyx settings.


Cor

Re: LyX and (ancient) Hebrew

[Cor Blom]

Op 03-12-16 om 21:43 schreef Scott Kostyshak:

Mike, I'm CC'ing a few people who have LyX + Hebrew knowledge. Perhaps
one of them is interested in joining this conversation about how we can
improve LyX to make it easier for users of Hebrew.


If I may offer some suggestions... I am not a programmer who can 
implement this, but I use Hebrew in LyX quite often, including ancient 
Hebrew with everything on it. Xetex is the only one, in my experience, 
that is really working.


The fonts are the issue, both screenfonts and document fonts. Lyx allows 
for both to set only one font and many fonts do not support rtl 
languages properly. I think what LibreOffice does (and I think Ms Office 
does the same) is a way to go: add a separate font setting for RTL 
languages, both for screen font as for the document font.


The other thing is that on screen, when I type a rtl text in a ltr 
documents, I have to mark that word as e.g. Hebrew before the sequence 
is right. I would be nice to have that done automatically. Xetex does it 
right, even if it is not marked as rtl. What would be great is an option 
to set not only a default rtl font, but also a default rtl language, 
that is set automatically by lyx in the document when rtl text is 
entered (and in Hebrew Lyx of course vice versa).


This probably needs a more extensive support for polyglossia.

Cor

Re: LyX and (ancient) Hebrew

[Cor Blom]

Op 03-12-16 om 22:06 schreef Scott Kostyshak:

On Sat, Dec 03, 2016 at 09:49:09PM +0100, Cor Blom wrote:

Op 03-12-16 om 20:57 schreef mn:

This font-switcheroo must go into the preamble, I am guessing now since
I am new to Xetex also.
But apparently this is not possible within LyX's gui?


No, it is not. You need polyglossia for that (which can be set in Lyx gui)
and something like this in the preamble:

\newfontfamily\hebrewfont[Script=Hebrew]{SBL Hebrew}

For each script a separate font can be set. Options like "Scale"
automatically scales the font so that it fits with the rest.


Just to make sure I understand this, it means that whenever text
language is set to Hebrew, then the font SBL Hebrew is used?

Scott



Yes.

Re: LyX and (ancient) Hebrew

[Cor Blom]

Op 03-12-16 om 20:57 schreef mn:

This font-switcheroo must go into the preamble, I am guessing now since
I am new to Xetex also.
But apparently this is not possible within LyX's gui?


No, it is not. You need polyglossia for that (which can be set in Lyx 
gui) and something like this in the preamble:


\newfontfamily\hebrewfont[Script=Hebrew]{SBL Hebrew}

For each script a separate font can be set. Options like "Scale" 
automatically scales the font so that it fits with the rest.


Cor

Re: lyx and dark color schemes

[Cor Blom]

Op 15-06-16 om 16:47 schreef Liviu Andronic:

On Wed, Jun 15, 2016 at 3:35 PM, Guillaume Munch <g...@lyx.org> 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






My colors are similar. See attached screenshot.

Regards,

Cor

Re: lyx and dark color schemes

[Cor Blom]

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.


Cor

Re: lyx and dark color schemes

[Cor Blom]

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

lyx and dark color schemes

[Cor Blom]

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

Re: 2.2.0beta1 tar balls are available

[Cor Blom]

Op 10-02-16 om 04:18 schreef Scott Kostyshak:

The tar balls and sig files are here:

https://www.dropbox.com/sh/y57gkjh8xo89ct4/AACbDGN83b4eq0cjkgR8tsq9a?dl=0

Packagers, please prepare your binaries.

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



Builds for openSUSE can be found here (although git is used, not the 
tarballs):


http://download.opensuse.org/repositories/home:/cornelisbb:/lyx-unstable/

Completely untested, but they build, both against qt4 as qt5.

Cor

Re: Last change in splash.lyx

[Cor Blom]

Op 04-02-16 om 22:59 schreef Jean-Pierre Chrétien:

Cor Blom  solcon.nl> writes:



On openSUSE it does not exist.


So how are the languages in TeXlive for openSUSE ?
Will the user have a similar problem than with Debian avatars
(i.e. no language package other than English loaded by default) ?



There are a number of languages installed, but not all. When LyX is 
installed, on my system I have then the following language packages:


texlive-collection-langczechoslovak
texlive-collection-langenglish
.. -langeuropean
-- -langfrench
.. -langgerman
.. -langitalian
.. -langpolish
.. -langportuguese
.. -langspanish

The are also collections for non-european languages, which are not 
installed by default (but maybe they are on a non-european system). I 
don't know how openSUSE knows which languages to install.


The way texlive is packaged follows upstream, as you can see when you 
look at the package list e.g. here:


http://download.opensuse.org/repositories/Publishing:/TeXLive/openSUSE_Leap_42.1/noarch/

So I think a solution for installing from TUG should, maybe with a small 
adaptation, also work on openSUSE.


Cor

Re: Last change in splash.lyx

[Cor Blom]

Op 04-02-16 om 00:35 schreef Uwe Stöhr:

Am 03.02.2016 um 15:32 schrieb Jean-Pierre Chrétien:


I think that it could also point out the texlive-lang-all packages which
avoids any concern about documents with foreign languages like some of
the manuals and examples.

Attached is a patch with a proposal.


Thanks Jean-Pierre,

only one question, does the package

texlive-lang-all

exists on other Linux distributions too (e.g. Ubuntu)? If so, do they
use the same name?

regards Uwe



On openSUSE it does not exist.

Regards, Cor

Re: Crash on Fedora 23 on copying or cutting text

[Cor Blom]

Op 09-09-15 om 11:30 schreef José Matos:

On Wednesday 09 September 2015 09:33:12 José Matos wrote:


For me the crash is easily reproducible, it is enough to select
some text and then to copy it or cut it, lyx always crashes.


The attached file is a simple example where this happens. Select the
first frame copy it and lyx crashes, both versions 2.1.4 and
2.2dev...

I created a simple file like the previous using lyx 2.2 and the
behaviour is the same.



The crash also happens on openSUSE (Tumbleweed in this case).

Cor

Re: Visual feedback of \textsc\emph

[Cor Blom]

Op 26-06-15 om 16:07 schreef Jean-Marc Lasgouttes:

Le 26/06/2015 15:20, Cor Blom a écrit :

Hi,

Sometimes I want text to be both small caps and emphasised. I can do
that and it is correct in the output, but in lyx itself it just shows as
regular text, indistuinguisable from normal text, which makes it hard to
use this. Is this a bug? Or is there something else wrong?

Using 2.1.3 on openSUSE 13.2


Hello,

Could you send an example file? I fail to get this emph+textsc
combination working in latex output anyway.

JMarc




Attached is an example file.


example.lyx
Description: application/lyx

Visual feedback of \textsc\emph

[Cor Blom]

Hi,

Sometimes I want text to be both small caps and emphasised. I can do 
that and it is correct in the output, but in lyx itself it just shows as 
regular text, indistuinguisable from normal text, which makes it hard to 
use this. Is this a bug? Or is there something else wrong?


Using 2.1.3 on openSUSE 13.2

Thanks,

Cor

Visual feedback of \textsc\emph

[Cor Blom]

Hi,

Sometimes I want text to be both small caps and emphasised. I can do 
that and it is correct in the output, but in lyx itself it just shows as 
regular text, indistuinguisable from normal text, which makes it hard to 
use this. Is this a bug? Or is there something else wrong?


Using 2.1.3 on openSUSE 13.2

Thanks,

Cor

Re: Visual feedback of \textsc\emph

[Cor Blom]

Op 26-06-15 om 16:07 schreef Jean-Marc Lasgouttes:

Le 26/06/2015 15:20, Cor Blom a écrit :

Hi,

Sometimes I want text to be both small caps and emphasised. I can do
that and it is correct in the output, but in lyx itself it just shows as
regular text, indistuinguisable from normal text, which makes it hard to
use this. Is this a bug? Or is there something else wrong?

Using 2.1.3 on openSUSE 13.2


Hello,

Could you send an example file? I fail to get this emph+textsc
combination working in latex output anyway.

JMarc




Attached is an example file.


example.lyx
Description: application/lyx

boost 1.58 and 2.1.x branch

[Cor Blom]

Hi,

openSUSE Factory/Tumbleweed now has boost 1.58. We build lyx against 
system boost and for 2.1.3 this fails now because of boost. In master 
this has been fixed, is it possible to backport this to branch?


If this is too complicated then I'll just build with internal boost 
until 2.2.


Thanks,

Cor

BTW: Factory/Tumbleweed also defaults to gcc5 now, but a fix for that is 
already part of branch.

Re: boost 1.58 and 2.1.x branch

[Cor Blom]

My problem has disappeared with updated packages. So never mind. Sorry 
for the noise.


Cor


Op 22-06-15 om 09:16 schreef Cor Blom:

Hi,

openSUSE Factory/Tumbleweed now has boost 1.58. We build lyx against
system boost and for 2.1.3 this fails now because of boost. In master
this has been fixed, is it possible to backport this to branch?

If this is too complicated then I'll just build with internal boost
until 2.2.

Thanks,

Cor

BTW: Factory/Tumbleweed also defaults to gcc5 now, but a fix for that is
already part of branch.

boost 1.58 and 2.1.x branch

[Cor Blom]

Hi,

openSUSE Factory/Tumbleweed now has boost 1.58. We build lyx against 
system boost and for 2.1.3 this fails now because of boost. In master 
this has been fixed, is it possible to backport this to branch?


If this is too complicated then I'll just build with internal boost 
until 2.2.


Thanks,

Cor

BTW: Factory/Tumbleweed also defaults to gcc5 now, but a fix for that is 
already part of branch.

Re: boost 1.58 and 2.1.x branch

[Cor Blom]

My problem has disappeared with updated packages. So never mind. Sorry 
for the noise.


Cor


Op 22-06-15 om 09:16 schreef Cor Blom:

Hi,

openSUSE Factory/Tumbleweed now has boost 1.58. We build lyx against
system boost and for 2.1.3 this fails now because of boost. In master
this has been fixed, is it possible to backport this to branch?

If this is too complicated then I'll just build with internal boost
until 2.2.

Thanks,

Cor

BTW: Factory/Tumbleweed also defaults to gcc5 now, but a fix for that is
already part of branch.

Re: Install package texlive-esint-type1

[Cor Blom]

Op 07-01-15 om 08:23 schreef Vincent van Ravesteijn:

Hi all,

To compile the User's guide, I had to manually install the package
texlive-esint-type1.

Shouldn't this be installed automatically when the lyx package is
installed ? I'm now at OpenSuse. Do other distros do install this
package ?

How can we inform the distros that this package is required ?

Vincent



For opensuse you can complain on this list. I try to pick up the 
opensuse specific things. :) I'll add this package to the list of 
required packages. Apparently missed this.


(I use recommends for everything lyx requires. In the default 
configuration recommends are treated as requires. Advanced users can, 
however, avoid the distro's texlive and you another source.)


BTW: is there somewhere a list of packages supported and required by lyx?

Cor

Re: Install package texlive-esint-type1

[Cor Blom]

Op 07-01-15 om 08:23 schreef Vincent van Ravesteijn:

Hi all,

To compile the User's guide, I had to manually install the package
"texlive-esint-type1".

Shouldn't this be installed automatically when the lyx package is
installed ? I'm now at OpenSuse. Do other distros do install this
package ?

How can we inform the distros that this package is required ?

Vincent



For opensuse you can complain on this list. I try to pick up the 
opensuse specific things. :) I'll add this package to the list of 
required packages. Apparently missed this.


(I use "recommends" for everything lyx requires. In the default 
configuration recommends are treated as requires. Advanced users can, 
however, avoid the distro's texlive and you another source.)


BTW: is there somewhere a list of packages supported and required by lyx?

Cor

Re: Python detection

[Cor Blom]

Op 13-04-13 03:09, Pavel Sanda schreef:

José Matos wrote:

So these are the facts. The question then is how do we want to proceed?


I thought we want to be 3.0 compatible and ditch 2.x series completely(?).
Otherwise it looks like just maintenace burden without profit.

What's the status of python 3 on fedora/debian/suse?

Pavel



on openSUSE 12.3 python 2 (2.7.3) is still default, but version 3 
(3.3.0) is available. Unknown when default will change.


Cor

Re: Python detection

[Cor Blom]

Op 13-04-13 03:09, Pavel Sanda schreef:

José Matos wrote:

So these are the facts. The question then is how do we want to proceed?


I thought we want to be >3.0 compatible and ditch 2.x series completely(?).
Otherwise it looks like just maintenace burden without profit.

What's the status of python 3 on fedora/debian/suse?

Pavel



on openSUSE 12.3 python 2 (2.7.3) is still default, but version 3 
(3.3.0) is available. Unknown when default will change.


Cor

Re: support for xdg-open (Linux) and open (Mac)

[Cor Blom]

Op 05-11-12 16:00, Kayvan Sylvan schreef:

In the Fedora distribution lyx packages, an xdg-open patch is applied
and the resulting lyx seems to work correctly.

openSUSE, mageia and ubuntu (as it is coming with the distro, don't know 
about lyx-ppa) are using the same patch (it was once committed to 
lyx-svn, but reversed). I am manintaining the openSUSE packages and I 
have never heard a complaint about them. The reason I include the patch 
is that it is easier for beginners and for more advanced users easy to 
change.


Sources with patch are here:

https://build.opensuse.org/package/files?package=lyxproject=Publishing

BTW: I have read the discussion of the past and understand the problems. 
It is not perfect.


Regards,

Cor

Re: support for xdg-open (Linux) and open (Mac)

[Cor Blom]

Op 05-11-12 16:00, Kayvan Sylvan schreef:

In the Fedora distribution lyx packages, an xdg-open patch is applied
and the resulting lyx seems to work correctly.

openSUSE, mageia and ubuntu (as it is coming with the distro, don't know 
about lyx-ppa) are using the same patch (it was once committed to 
lyx-svn, but reversed). I am manintaining the openSUSE packages and I 
have never heard a complaint about them. The reason I include the patch 
is that it is easier for beginners and for more advanced users easy to 
change.


Sources with patch are here:

https://build.opensuse.org/package/files?package=lyx=Publishing

BTW: I have read the discussion of the past and understand the problems. 
It is not perfect.


Regards,

Cor

Re: LyX 2.0.3 Sources Available

[Cor Blom]

Op dinsdag 21 februari 2012 07:22:55 schreef Stephan Witt:
 Am 20.02.2012 um 23:55 schrieb Cor Blom:
  Op maandag 20 februari 2012 23:02:38 schreef Cor Blom:
  Op maandag 20 februari 2012 22:39:46 schreef Liviu Andronic:
  On Mon, Feb 20, 2012 at 10:19 PM, Cor Blom corne...@solcon.nl wrote:
  The only way I can understand that is that lyx is looking in
  /usr/share/myspell for the dictionaries.
  
  This is what seems to happen on Ubuntu Lucid. I have installed LyX
  2.0.3 with a clean profile (no manual hunspell path specified) and
  LyX
  now automatically detects the hunspell dictionaries located in:
  liv@liv-laptop:~$ ls /usr/share/myspell -l
  total 8
  drwxr-xr-x 2 root root 4096 2012-02-08 09:24 dicts
  drwxr-xr-x 3 root root 4096 2010-04-29 17:45 infos
  
  And I have no symlink specified here:
  liv@liv-laptop:~$ ls /usr/share/lyx/dicts
  ls: cannot access /usr/share/lyx/dicts: No such file or directory
  
  on openSUSE I still have to tell lyx where the hunspell dicts can be
  found (either via lyxrc.dist or via symlinks). Will investigate later
  when I have some time. It is not really a problem as the old method
  was working fine. 
  Ok, found the difference between specifying the hunspell dicts path
  explicitly and not. When the path is explicitly/manually given, that
  path is used (in my case /usr/share/myspell), but when the path is left
  empty (and I used a clean profile) /usr/share/myspell/dicts is used.
  That directory does not exist.
  
  So when no manual hunspell path is specified, lyx on opensuse is looking
  in the wrong directory (adding dicts to the path).
 
 I've introduced the lookup for dicts in /usr/share/myspell.
 At that time I thought about a configure option too - but I didn't introduce
 one.
 
 The dicts sub dir directory addition I got from the rpm file list of the
 dictionary packages. So, yes, effectively LyX looks for the hunspell
 dictionaries in /usr/share/myspell/dicts as a last resort.
 
 The other places LyX is looking for system dictionaries is the directory
 dicts in the LyX system dir. For your rpm this would be
 /usr/share/lyx/dicts I'd guess.
 
Yes, it is looking in three directories: /.lyx/dicts, /usr/share/lyx/dicts and 
/usr/share/myspell/dicts. But not /usr/share/myspell, where the dictionaties 
are actually installed. (running lyx -dbg files gives me this info).

Cor

Re: LyX 2.0.3 Sources Available

[Cor Blom]

Op dinsdag 21 februari 2012 07:22:55 schreef Stephan Witt:
> Am 20.02.2012 um 23:55 schrieb Cor Blom:
> > Op maandag 20 februari 2012 23:02:38 schreef Cor Blom:
> >> Op maandag 20 februari 2012 22:39:46 schreef Liviu Andronic:
> >>> On Mon, Feb 20, 2012 at 10:19 PM, Cor Blom <corne...@solcon.nl> wrote:
> >>>> The only way I can understand that is that lyx is looking in
> >>>> /usr/share/myspell for the dictionaries.
> >>> 
> >>> This is what seems to happen on Ubuntu Lucid. I have installed LyX
> >>> 2.0.3 with a clean profile (no manual hunspell path specified) and
> >>> LyX
> >>> now automatically detects the hunspell dictionaries located in:
> >>> liv@liv-laptop:~$ ls /usr/share/myspell -l
> >>> total 8
> >>> drwxr-xr-x 2 root root 4096 2012-02-08 09:24 dicts
> >>> drwxr-xr-x 3 root root 4096 2010-04-29 17:45 infos
> >>> 
> >>> And I have no symlink specified here:
> >>> liv@liv-laptop:~$ ls /usr/share/lyx/dicts
> >>> ls: cannot access /usr/share/lyx/dicts: No such file or directory
> >> 
> >> on openSUSE I still have to tell lyx where the hunspell dicts can be
> >> found (either via lyxrc.dist or via symlinks). Will investigate later
> >> when I have some time. It is not really a problem as the old method
> >> was working fine.> 
> > Ok, found the difference between specifying the hunspell dicts path
> > explicitly and not. When the path is explicitly/manually given, that
> > path is used (in my case /usr/share/myspell), but when the path is left
> > empty (and I used a clean profile) /usr/share/myspell/dicts is used.
> > That directory does not exist.
> > 
> > So when no manual hunspell path is specified, lyx on opensuse is looking
> > in the wrong directory (adding "dicts" to the path).
> 
> I've introduced the lookup for dicts in /usr/share/myspell.
> At that time I thought about a configure option too - but I didn't introduce
> one.
> 
> The "dicts" sub dir directory addition I got from the rpm file list of the
> dictionary packages. So, yes, effectively LyX looks for the hunspell
> dictionaries in "/usr/share/myspell/dicts" as a last resort.
> 
> The other places LyX is looking for system dictionaries is the directory
> dicts in the LyX system dir. For your rpm this would be
> "/usr/share/lyx/dicts" I'd guess.
> 
Yes, it is looking in three directories: /.lyx/dicts, /usr/share/lyx/dicts and 
/usr/share/myspell/dicts. But not /usr/share/myspell, where the dictionaties 
are actually installed. (running lyx -dbg files gives me this info).

Cor

Re: LyX 2.0.3 Sources Available

[Cor Blom]

Op zondag 19 februari 2012 11:18:44 schreef Richard Heck:
 LyX 2.0.3 source tarballs are available from:
  http://frege.brown.edu/lyx/
 Please let me know if there are any difficulties. I'll plan to release
 late this week (Friday or Saturday) if there are not.
 
 Please note that branch is still closed.
 
 Richard

It is building fine on all version of openSUSE. But I have a problem with 
hunspell. If I understand correctly, user or packager no longer have to give 
an explicit directory for the hunspell dictionaries, because 
/usr/share/myspell is used by default. So I removed the line 
'\hunspelldir_path /usr/share/myspell' from lyxrc.dist. But in the resulting 
package hunspell is no longer working and the user has to provide the path to 
the dictionaries himself.

Cor

P.S. My lyx testing project can be found here:

https://build.opensuse.org/package/show?package=lyxproject=home%3Acornelisbb%3Alyx-
unstable

Re: LyX 2.0.3 Sources Available

[Cor Blom]

Op maandag 20 februari 2012 14:59:08 schreef Pavel Sanda:
 Cor Blom wrote:
  It is building fine on all version of openSUSE. But I have a problem
  with
  hunspell. If I understand correctly, user or packager no longer have to
  give an explicit directory for the hunspell dictionaries, because
  /usr/share/myspell is used by default. So I removed the line
  '\hunspelldir_path /usr/share/myspell' from lyxrc.dist. But in the
  resulting package hunspell is no longer working and the user has to
  provide the path to the dictionaries himself.
 
 This issue should be fixed if you create softlink (gentoo solution)
 /usr/share/lyx/dicts - /usr/share/myspell/ (or whatever location you use)
 /usr/share/lyx/thes - /usr/share/myspell/
 
It is working that way. Thanks!

Is this a bug, or is it intended to work this way?

Cor

Re: LyX 2.0.3 Sources Available

[Cor Blom]

Op maandag 20 februari 2012 21:49:18 schreef Pavel Sanda:
 Cor Blom wrote:
  Is this a bug, or is it intended to work this way?
 
 RELEASE-NOTES clearly states:
 System-wide hunspell dictionaries are in standard Linux installs
 looked up at /usr/local/share/lyx/dicts/.
 
I missed that. Sorry.

But I was set on the wrong foot by this paragraph in ANNOUNCE:

- Add the directory /usr/share/myspell as default location for dictionary
  lookup of hunspell spell checker backend (a common location on linux).
  Detect value change of preferences path to hunspell dictionaries
  to avoid the need for a restart.  This is related to bug 7884.

The only way I can understand that is that lyx is looking in 
/usr/share/myspell for the dictionaries.

Cor