Ipe 7.2.29 fails to run LaTex on Arch linux

[MiuKaShi]

After update to ipe-7.2.29-1, text cannot be rendered and show

I checked that xelatex pdflatex lualtex all exist under /usr/bin/, please fix the bug

[otfried]

What is your exact operating system? How exactly did you install Ipe 7.2.29? Can you include a screenshop of Help -> Show configuration?

[MiuKaShi]

Sorry for late reply. Here is my new test

OS: Artix (Based on Arch Linux) Package: ipe 7.2.29-1 From AUR

I found that when setting prefs.tex_engine = "xetex" it shows that LaTex is not installed (I have xetex in /usr/bin/).

Change to prefs.tex_engine = "default" I got

The "Compiling LaTex" window doesn't disappear automatically and the ipe gets stuck. I checked the ipetemp.pdf file had the text has been successfully created. So I think it's a bug in ipe, and not a problem in latex.

[otfried]

Arch Linux uses cutting edge versions of all libraries, so you need to expect things to break.

I have spent too many hours in the past looking for problems in Ipe that in the end turned out to be bugs in Qt...

Can you attach a screenshot of the libraries and the configuration you are using: Help menu -> Show libraries and Help menu -> Show configuration ?

If I have some free time, I can try to find a live image of Arch Linux and see if I can reproduce these problems, but until then you are much better off reporting the issue on the Arch bug tracker.

You can also try adding prefs.freeze_in_latex = true to your preferences and see if this removes the problem.

[Mortal]

@MiuKaShi Does it work if you switch from xetex to luatex, and put prefs.freeze_in_latex = true in your ~/.ipe/ipelets/prefs.lua? For me (I also use Arch btw), xetex doesn't work in either 7.2.28 or 7.2.29 - I suspect it's an issue with xetex on Arch Linux and not an issue with Ipe.

[otfried]

When I look at the file list for the texlive-xetex package, it lists:

usr/bin/xelatex-unsafe
usr/bin/xetex-unsafe

Do you actually have /usr/bin/xelatex? Is it a symbolic link, or something else? Can you call xelatex from the command line?

[galexej]

At the risk of making things more complicated: I am using an up-to-date Arch with 7.2.29 just fine. No errors here. But two of my coworkers have the same problem, so I came here...

Default settings work great, prefs.tex_engine = "xetex" does not work, but prefs.tex_engine = "xelatex" does work fine.

By the way, the binary for xelatex is in the package texlive-bin:

alex@iris ~/.ipe/ipelets % pacman -Qo $(which xelatex)
/usr/bin/xelatex ist in texlive-bin 2024.2-2 enthalten

If I can test anything to help debugging, let me know.

[otfried]

The valid names for the tex_engine are "default", "pdftex", "xetex", "luatex". If you set it to "xelatex", the tex engine is simply not changed at all, so it should be running with the default engine (pdflatex) - you should be able to see that in the log file.

You do not by any chance have prefs.freeze_in_latex set on your computer?

[otfried]

So one simple test you could do:

cd ~/.ipe/latexrun
xelatex ipetemp.tex

The output should start with This is XeTeX, Version 3.14159 and end with Transcript written on ipetemp.log.

[otfried]

Also, it should produce a fresh ipetemp.log file that starts with

This is XeTeX, Version 3.141592653-2.6-0.999993 (TeX Live 2022/dev/Debian) (preloaded format=xelatex 2024.5.27)  27 MAY 2024 16:37
entering extended mode
 restricted \write18 enabled.
 %&-line parsing enabled.
**ipetemp.tex

or similar.

[galexej]

Okay, it turns out I never had xelatex fully installed. I installed the remaining packages, now I can compile successfully with xelatex outside of IPE, but inside IPE, it breaks sometimes.

• prefs.tex_engine = "pdftex" and prefs.freeze_in_latex = false are fine,
• prefs.tex_engine = "xetex" and prefs.freeze_in_latex = false are broken,
• prefs.tex_engine = "pdftex" and prefs.freeze_in_latex = true are fine,
• prefs.tex_engine = "xetex" and prefs.freeze_in_latex = true are fine (and I checked that it actually compiled with xelatex)

[therealmaxi]

I don't know whether this helps to localize the error, but I got the message

QObject::installEventFilter(): Cannot filter events for objects in a different thread.

in my terminal when trying to compile latex code.

[otfried]

I don't know whether this helps to localize the error, but I got the message

QObject::installEventFilter(): Cannot filter events for objects in a different thread.

in my terminal when trying to compile latex code.

Yes, this is most likely the reason why the "Compiling Latex" dialog hangs and does not disappear. We'll have to figure out what has changed in Qt - what Qt version are you using? I've looked at the Qt release notes, but didn't find any leads yet. It's either a behaviour change that Ipe needs to accomodate, or simply a bug.

[otfried]

* `prefs.tex_engine = "xetex"` and `prefs.freeze_in_latex = false` are broken,

With broken you mean that it hangs in the "Compiling Latex" dialog? And you don't get that with pdflatex? Mysterious.

[galexej]

Sorry for the vague "broken"; I mean, it just freezes with the "Compiling Latex" dialog, but unlike @therealmaxi I do not have any error output in my terminal.

Edit: Bonus image with pdflatex:

[galexej]

Another thing: independently of settings, I get stuck when opening an external editor in the "Waiting for external editor" dialog, no errors in terminal here either.

[galexej]

With broken you mean that it hangs in the "Compiling Latex" dialog? And you don't get that with pdflatex? Mysterious.

I now managed to get it stuck with prefs.tex_engine = "pdftex" and prefs.freeze_in_latex = false if I simply run stress -c 8 in the background. Is the appearance of the box tied to performance? Like, if latex finishes quickly enough, it won't open at all?

Packet qt6-base is version 6.7.1-2 here, by the way.

[otfried]

Like, if latex finishes quickly enough, it won't open at all?

That's exactly right - if latex finishes within 300ms, the dialog doesn't open.

So it seems what's broken is the mechanism that closes the dialog once latex has finished. In principle, the thread should emit a signal done that then calls done on the dialog.

[galexej]

Just to confirm that it worked before: I just downgraded to IPE 7.2.28 (because downgrading all QT packages seemed too complicated), and the dialogs close just fine in that version.

[MiuKaShi]

After testing, the solution for ipe-7.2.29 was found pacman -S texlive-xetex --overwrite "*" then with prefs.tex_engine = "xetex" prefs.freeze_in_latex = true

Now, ipe is working fine.

[otfried]

I've now downloaded a live image of Manjaro Linux, which allowed me to see what exactly is happening in Qt 6.7. It turns out that the implementation of QObject::connect has changed when the "slot" is a lambda, it is now called in the thread that emitted the signal.

After quite some googling and debugging I have rewritten the wait dialog again, and this version seems to work fine on both Qt 6.2 and 6.7. And I now understand much better what it takes to send signals across threads in Qt.

If you compile Ipe from source, just compile again from head (https://github.com/otfried/ipe/commit/d00366b5b0c89562199e7bace7a55330fc0d031c).

I guess I'll make a new release shortly, but of the Ipe sources only, so that Dmitriy can make a new AUR package.

[Mortal]

Well done Otfried - I can confirm that with the latest commit if works for me, with luatex and without freeze_in_latex.

I simply added some code in the PKGBUILD of the AUR package to apply d00366b5b0c89562199e7bace7a55330fc0d031c as a plain patch on top of the 7.2.29 release - that was the easiest way for me to test it.

[MiuKaShi]

Here, I add a ipe-git version PKGBUILD. May help someone

_pkgname=ipe
pkgname=ipe-git
pkgver=r98.d00366b
pkgrel=1
pkgdesc="The extensible drawing editor"
url="https://github.com/otfried/ipe"
depends=('lua' 'qt6-base' 'qt6-svg' 'freetype2' 'zlib' 'poppler' 'hicolor-icon-theme' 'gsl' 'libspiro' 'qtspell')
arch=('i686' 'x86_64')
license=("GPL")
conflicts=('ipe')
source=("git+https://github.com/otfried/ipe.git"
    "ipe.bash-completion::https://aur.archlinux.org/cgit/aur.git/plain/ipe.bash-completion?h=ipe"
    "config.patch::https://aur.archlinux.org/cgit/aur.git/plain/config.patch?h=ipe"
    "ipe.desktop::https://aur.archlinux.org/cgit/aur.git/plain/ipe.desktop?h=ipe"
)

pkgver() {
    cd "$srcdir/$_pkgname"
    printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

prepare() {
    cd "$srcdir/$_pkgname/src"
    patch config.mak <"$srcdir/config.patch"
    sed -i '/#include <xlocale.h>/d' ipelib/ipeplatform.cpp

    sed -i -e 's/"ipefonts.h"/<ipefonts.h>/' ipepresenter/ipepresenter.h
    sed -i -e 's/"ipethumbs.h"/<ipethumbs.h>/' ipepresenter/ipepresenter_qt.cpp
}

build() {
    # Ipe
    cd "$srcdir/$_pkgname/src"
    make IPEPREFIX=/usr
}

package() {
    # Ipe
    cd "$srcdir/$_pkgname/src"
    INSTALL_ROOT="$pkgdir" make install IPEPREFIX=/usr

    # Lua binding
    mkdir "$pkgdir/usr/lib/lua"
    ln -s /usr/lib/libipelua.so "$pkgdir/usr/lib/lua/ipe.so"

    # Bash completion
    mkdir -p "$pkgdir/etc/bash_completion.d"
    install "$srcdir/ipe.bash-completion" "$pkgdir/etc/bash_completion.d/ipe"

    # Desktop file
    mkdir -p "$pkgdir/usr/share/applications"
    install -m644 "$srcdir/ipe.desktop" "$pkgdir/usr/share/applications/ipe.desktop"

    # Icons
    mkdir -p "$pkgdir/usr/share/icons/hicolor/16x16/apps"
    mkdir -p "$pkgdir/usr/share/icons/hicolor/32x32/apps"
    mkdir -p "$pkgdir/usr/share/icons/hicolor/64x64/apps"
    mkdir -p "$pkgdir/usr/share/icons/hicolor/128x128/apps"
    mkdir -p "$pkgdir/usr/share/icons/hicolor/256x256/apps"
    mkdir -p "$pkgdir/usr/share/icons/hicolor/512x512/apps"
    install -m644 "$srcdir/$_pkgname/artwork/ipe.iconset/icon_16x16.png" "$pkgdir/usr/share/icons/hicolor/16x16/apps/ipe.png"
    install -m644 "$srcdir/$_pkgname/artwork/ipe.iconset/icon_32x32.png" "$pkgdir/usr/share/icons/hicolor/32x32/apps/ipe.png"
    install -m644 "$srcdir/$_pkgname/artwork/ipe.iconset/icon_64x64.png" "$pkgdir/usr/share/icons/hicolor/64x64/apps/ipe.png"
    install -m644 "$srcdir/$_pkgname/artwork/ipe.iconset/icon_128x128.png" "$pkgdir/usr/share/icons/hicolor/128x128/apps/ipe.png"
    install -m644 "$srcdir/$_pkgname/artwork/ipe.iconset/icon_256x256.png" "$pkgdir/usr/share/icons/hicolor/256x256/apps/ipe.png"
    install -m644 "$srcdir/$_pkgname/artwork/ipe.iconset/icon_512x512.png" "$pkgdir/usr/share/icons/hicolor/512x512/apps/ipe.png"
}

# vim: ft=sh syn=sh et ts=2 sw=2
md5sums=('SKIP'
    '694f0d5402655901be385647e5d8d6e3'
    '9b8ef63e12862f93ab8907a5763fb683'
    '19fd2cac2564125afa0149105d00d3dd')

[DaKassian]

Hi! How can I use this PKGBUILD or anything to resolve this issue? Can I use this file anyhow to download it or do I have to download the code and then change some file? I tried downloading the code from git and install it, but it didn't resolve the issue.

[MiuKaShi]

Hi! How can I use this PKGBUILD or anything to resolve this issue? Can I use this file anyhow to download it or do I have to download the code and then change some file? I tried downloading the code from git and install it, but it didn't resolve the issue.

I just updated the PKGBUILD content. Now you can just copy and save it as a PKGBUILD file, and then run makepkg -sfi and it should work fine.

[DaKassian]

makepkg -sfi ==> Making package: ipe-git r98.d00366b-1 (Mi 29 Mai 2024 11:12:00 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Cloning ipe git repo... Cloning into bare repository '---/ipe-master/ipe'... remote: Enumerating objects: 1312, done. remote: Counting objects: 100% (531/531), done. remote: Compressing objects: 100% (388/388), done. remote: Total 1312 (delta 266), reused 259 (delta 141), pack-reused 781 Receiving objects: 100% (1312/1312), 2.22 MiB | 8.55 MiB/s, done. Resolving deltas: 100% (639/639), done. ==> ERROR: ipe.bash-completion was not found in the build directory and is not a URL. Do I have to execute this in the cloned repository? In /src?

[MiuKaShi]

makepkg -sfi ==> Making package: ipe-git r98.d00366b-1 (Mi 29 Mai 2024 11:12:00 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Cloning ipe git repo... Cloning into bare repository '---/ipe-master/ipe'... remote: Enumerating objects: 1312, done. remote: Counting objects: 100% (531/531), done. remote: Compressing objects: 100% (388/388), done. remote: Total 1312 (delta 266), reused 259 (delta 141), pack-reused 781 Receiving objects: 100% (1312/1312), 2.22 MiB | 8.55 MiB/s, done. Resolving deltas: 100% (639/639), done. ==> ERROR: ipe.bash-completion was not found in the build directory and is not a URL. Do I have to execute this in the cloned repository? In /src?

Did you use my updated PKGBUILD content, which already contains the download URL for the patch?

[DaKassian]

makepkg -sfi ==> Making package: ipe-git r98.d00366b-1 (Mi 29 Mai 2024 11:12:00 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Cloning ipe git repo... Cloning into bare repository '---/ipe-master/ipe'... remote: Enumerating objects: 1312, done. remote: Counting objects: 100% (531/531), done. remote: Compressing objects: 100% (388/388), done. remote: Total 1312 (delta 266), reused 259 (delta 141), pack-reused 781 Receiving objects: 100% (1312/1312), 2.22 MiB | 8.55 MiB/s, done. Resolving deltas: 100% (639/639), done. ==> ERROR: ipe.bash-completion was not found in the build directory and is not a URL. Do I have to execute this in the cloned repository? In /src?

Did you use my updated PKGBUILD content, which already contains the download URL for the patch?

Yes, I did.

[muckis23]

Well done Otfried - I can confirm that with the latest commit if works for me, with luatex and without freeze_in_latex.

I simply added some code in the PKGBUILD of the AUR package to apply d00366b as a plain patch on top of the 7.2.29 release - that was the easiest way for me to test it.

I have the same problem...

@Mortal thx for the fix, could you tell me where I can find the updated AUR package?

Like here (https://aur.archlinux.org/packages/ipe), it is not included yet... or do I have to be patient?

[mariohevia]

I can confirm MiuKaShi's PKGBUILD with the latest commit fixed this for me on Manjaro.