lyx 1.5.3-1 crashes as soon as it starts

Exactly the same happens to me

I too get the same thing.
Occassionally, I can get lyx started by reinstalling it, but it still doesn't load any document.
When running empty, telling it to reconfigure yields a "Reconfiguration has failed" message,
with the only error indicated on the stderr output being "mktexmf ecrm1000" failing.

This is because of new faulty qt4.4 from hardy backports. Use synaptic, remove all qt, libqt, libqtcore and everything else qt (lyx, skype and stellarium will follow). Then remove hardy-backports from the sources and resync. Then install libqt4-core and libqt4-gui at version 4.3. Then lyx and everythong else. Now everything should be fine.

Thanks so much, that resolved the problem

Hi manuel fernandez it's 1.5.3 version of lyx and not 1.3.5 :)
I have the same crash problem and i have to launch lyx twice to open the desired document. I hope that this problem will be fixed.

Yes, you are right, I have corrected to 1.5.3.1.

I have tried opening two lyx sessions. When I open a file with the first it crashes, when openning with the second session it sometimes opens fine and sometimes crashes.

I updated my computer yesterday & it broke lyx with the same SIGSEGV. However this relates to lyx 1.5.4 (/usr/local/bin/lyx) that I have compiled myself. Lyx 1.5.3 from ubuntu (/usr/bin/lyx) did not have this bug on my machine.
So far so good: one might argue that I should have recompiled lyx for the interfaces to match after the update.

Yet, getting rid of ~/.config/Trolltech.conf solved the problem!
Please try by yourself :
$ mv ~/.config/Trolltech.conf ~/.config/Trolltech.conf.bak
and please report if it solves the problem.

This might mean this bug is related to bug #197950 -- the symptoms are different but the workaround is the same.

I add qt4 to the list, since it seems to be related to qt4. (before you ask, yes, yesterday's update got qt4.4 on my computer)

Good catch. I just tried this now and so far I seem to be getting no crashes. If it crashes again I will post back a rebuttal. But again... good catch :)

I renamed Trolltech.conf but lyx (or some other program) made a new Trolltech.conf and lyx crashes again.

Just confirming that mine is crashing too. Same thing as previous poster, Trolltech gets recreated and then lyx starts crashing again.

Here's the behavior in bug #197950 : the bug vanishes but qt modifies Trolltech.conf at each run of lyx. At some point, it becomes corrupted and the bug reappear. Then one has to start again and delete Trolltech.conf, and so on.

Hence if qt creates Trolltech.conf again and at some point applications crash again, that's perfectly normal: that's the bug we're chasing.

Manuel, are you sure you can't even get lyx to run at least once after removing Trolltech.conf?

Can some of you do the following?:
1. Create a proper Trolltech.conf with qtconfig-qt4 (after deleting it) and make a backup of it.
2. Then play with lyx until you can get it to crash and make a diff, so that we can see the difference.

renamed Trolltech.conf, tried to start lyx and it immediately crashed (did not work even once)
attrached is the generated file
However, if I then try to launch lyx again it comes up (without crashing) but as soon as I try to open a file it crashes.

In the following bug there is a comparison between Trolltecj.conf files, I do not understand a word but it seems that it is what you are searching gadm
http://bugzilla.lyx.org/show_bug.cgi?id=4819

this is the file produced by qtconfig-qt4

this is the one produced by lyx, over- writting the previous one and crashing

(looks quite different from those reported in bug 4819 mentioned above)

Yes, that's what I am looking for -- I was aware of the diff you mention, since the person who did post it is a.k.a. myself :)
Well, in bug #197950 it seems to be related to the "filedialog" thing of Trolltech.conf -- but there's no sign of it in your Trolltech.conf. Don't hesitate to post a diff if it evolves.

Yet, our two bugs need not be duplicates in order to be related...

Maybe Peitschie has something else with his Trolltech.conf?

As soon as I open a document, or even select 'new', I get:

jorgen@brain:~$ lyx foo.lyx
QPaintEngine::setSystemClip: Should not be changed while engine is active
QPaintEngine::setSystemClip: Should not be changed while engine is active
QWidgetPrivate::beginSharedPainter: Painter is already active

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help->Introduction and send us a bug report, if necessary. Thanks !
Bye.
Aborted

The configuration created by lyx is shown below, compared to the default configuration created by qtconfig-qt4.

--- .config/Trolltech.conf.lyx-1.5.3-1 2008-05-09 19:12:47.000000000 +0200
+++ .config/Trolltech.conf.qtconfig-qt4 2008-05-09 19:16:30.000000000 +0200
@@ -1,20 +1,5 @@
 [Qt%20Plugin%20Cache%204.4.false]
 usr\lib\qt4\plugins\inputmethods\libqimsw-multi.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
-usr\lib\qt4\plugins\imageformats\libqgif.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
-usr\lib\qt4\plugins\imageformats\libqico.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
-usr\lib\qt4\plugins\imageformats\libqjpeg.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
-usr\lib\qt4\plugins\imageformats\libqmng.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
-usr\lib\qt4\plugins\imageformats\libqsvg.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:31
-usr\lib\qt4\plugins\imageformats\libqtiff.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
-usr\lib\qt4\plugins\iconengines\libqsvgicon.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:31

 [Qt%20Factory%20Cache%204.4]
 com.trolltech.Qt.QInputContextFactoryInterface%3A\usr\lib\qt4\plugins\inputmethods\libqimsw-multi.so=2008-05-06T23:17:16, imsw-multi
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqgif.so=2008-05-06T23:17:16, gif
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqico.so=2008-05-06T23:17:16, ico
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqjpeg.so=2008-05-06T23:17:16, jpeg, jpg
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqmng.so=2008-05-06T23:17:16, mng
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqsvg.so=2008-05-06T23:17:31, svg
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqtiff.so=2008-05-06T23:17:16, tiff, tif
-com.trolltech.Qt.QIconEngineFactoryInterfaceV2%3A\usr\lib\qt4\plugins\iconengines\libqsvgicon.so=2008-05-06T23:17:31, svg
-com.trolltech.Qt.QIconEngineFactoryInterface%3A\usr\lib\qt4\plugins\iconengines\libqsvgicon.so=2008-05-06T23:17:31

NOTE: Doing

mv ~/.config/Trolltech.conf ~/.config/Trolltech.conf.bak

does NOT help, but logging out and in again (presumably the X server restart) makes LyX for a very short time (i.e. opening one or two documents).

Just writing to confirm Håvard H. Garnes' workaround:

>This is because of new faulty qt4.4 from hardy backports. Use synaptic, remove all qt, libqt, libqtcore and everything else qt (lyx, skype and
>stellarium will follow). Then remove hardy-backports from the sources and resync. Then install libqt4-core and libqt4-gui at version 4.3. Then
>lyx and everythong else. Now everything should be fine.

I have now opened and closed several documents, and LyX appears stable. The ~/.config/Trolltech.conf that lyx creates under QT 4.3 looks as follows (I have no idea whether this is useful, but here goes):

--- .config/Trolltech.conf.lyx-1.5.3-1.qt4.3 2008-05-09 19:31:26.000000000 +0200
+++ .config/Trolltech.conf.lyx-1.5.3-1.qt4.4 2008-05-09 19:12:47.000000000 +0200
@@ -1,18 +1,20 @@
-[Qt%20Factory%20Cache%204.3]
-com.trolltech.Qt.QIconEngineFactoryInterface%3A\usr\lib\qt4\plugins\iconengines\libqsvg.so=2008-04-09T19:41:59
-com.trolltech.Qt.QIconEngineFactoryInterfaceV2%3A\usr\lib\qt4\plugins\iconengines\libqsvg.so=2008-04-09T19:41:59, svg
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqgif.so=2008-04-09T19:41:59, gif
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqjpeg.so=2008-04-09T19:41:59, jpeg, jpg
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqmng.so=2008-04-09T19:41:59, mng
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqsvg.so=2008-04-09T19:41:59, svg
-com.trolltech.Qt.QImageIOHandlerFactoryInterface%3A\usr\lib\qt4\plugins\imageformats\libqtiff.so=2008-04-09T19:41:59, tiff, tif
-com.trolltech.Qt.QInputContextFactoryInterface%3A\usr\lib\qt4\plugins\inputmethods\libqimsw-multi.so=2008-04-09T19:41:59, imsw-multi
+[Qt%20Plugin%20Cache%204.4.false]
+usr\lib\qt4\plugins\inputmethods\libqimsw-multi.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
+usr\lib\qt4\plugins\imageformats\libqgif.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
+usr\lib\qt4\plugins\imageformats\libqico.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
+usr\lib\qt4\plugins\imageformats\libqjpeg.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
+usr\lib\qt4\plugins\imageformats\libqmng.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
+usr\lib\qt4\plugins\imageformats\libqsvg.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:31
+usr\lib\qt4\plugins\imageformats\libqtiff.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:16
+usr\lib\qt4\plugins\iconengines\libqsvgicon.so=40400, 0, x86_64 Linux g++-4 full-config, 2008-05-06T23:17:31

-[Qt%20Plugin%20Cache%204.3.debug]
-usr\lib\qt4\plugins\iconengines\libqsvg.so=40304, 1, x86_64 Linux g++-4 full-config, 2008-04-09T19:41:59
-usr\lib\qt4\plugins\imageformats\libqgif.so=40304, 1, x86_64 Linux g++-4 full-config, 2008-04-09T19:41:59
-usr\lib\qt4\plugins\imageformats\libqjpeg.so=40304, 1, x86_64 Linux g++-4 full-config, 2008-04-09T19:41:59
-usr\lib\qt4\plugins\imageformats\libqmng.so=40304, 1, x86_64 Linux g++-4 full-config, 2008-04-09T19:41:59
-usr\lib\qt4\plugin...

This seams to be a duplicate bug of bug #228596, #228701.

Hi together,
so this happend together with an update on Mai 8th.

The problem is
  <<<<< WITH BACKPORTS UPDATE ENABLED >>>>>

This updates libqt4* to version 4.x, whereas hardy comes with version 3.4.x.

I did the following rollback and everything works like expected:

1. Disable the backports updates (unsupported) in the update manager
2. apt-get remove libqt4-dbus libqt4-test libqtcore4 libqt4-xml libqtgui4 libqt4-network libqt4-script libqt4-opengl libqt4-svg libqt4-assistant
3 apt-get clean
  (! removes all previously downloaded deb files from /var/cache/apt/archives)
4. apt-get install --reinstall libqt4-gui libqt4-core
5. Check, if everything went fine:
apt-get -f install or
dpkg --configure -a

This procedure should deactualise to the previous version libqt4 3.4.x.

If this does not help, download all relevant (3.4.x) libqt4* packages from a download mirror of
"packages.ubuntu.com/hardy/" and install them manually with

dpkg -i --force-all libqt4*.deb

Check the Installation finally with
apt-get -f install or
dpkg --configure -a

Forget to mention,
like Havards post above (https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/228067/comments/3) said:
It might be necessary to uninstall "all qt libs and programs" and reinstall them afterwards. Do not fear, you won't loose any of your program settings ;)

But again: DISABLE BACKPORTS UPDATES !

With the last updates of QT (4.4.0-1ubuntu3~hardy1) I have no more crash but still the warning messages.

I still have the same behaviour with lyx crashes even with update of qt's 4.4.0-1ubuntu3~hardy1

after several tries it sometimes works and sometimes not. Highly unstable.

the lyx team comment that the bug is solved in version 1.5.5 due to come out this monday (12 may), see

http://bugzilla.lyx.org/show_bug.cgi?id=4835

I also still have the crashes with the last update of qt 4.4.0-1ubuntu3~hardy1 !!
I removed old Trolltech.conf file but no changes happens.

Just to say that in my PC with amd64 version of hardy crashes still happen frequently and in my second PC with i386 version of hardy I have no more crashes !!
The two PC are both up to date. Is it an amd64 dependent bug ? What in your case ?

> crashes !! The two PC are both up to date. Is it an amd64 dependent bug ?
> What in your case ?

Definitely not AMD64 related, I still have reproduceable crashes on i386

Lyx crashes and is unstable with qt 4.4.0-1ubuntu3~hardy1 in either my server Intel xeon EMT64 and also my i386 laptop.

lyx 1.5.5 compiles ok in kubuntu hardy, works nicely with qt4.4.0-1ubuntu3~hardy1, without crashes (so far!)

download source from http://www.lyx.org/news.php

lyx 1.5.5 compiles ok in 64 bit architecture, specifically xeon 64EMT kubuntu hardy, with qt4.4.0-1ubuntu3~hardy1
download source from http://www.lyx.org/News
(News with capital N)

As others have said, the best solution for those stuck with LyX not working is to build LyX locally. I suggest doing this *without* installing your built LyX, just by building it, meanwhile keeping your Ubuntu LyX installation intact. This will have no effect at all on your Ubuntu installation and is 100% safe! Eventually, I'm sure the qt4 problem will be solved in the repository and you'll be able to go back to your Ubuntu LyX without any problems. Then, you can simply delete the directory with the temporary LyX.

Here's how to do it, step by step. Easy, I promise! Works on 32- and 64-bit systems.

1. Make sure you have the build tools you need. For my system, this was good enough:

sudo aptitude install build-essential libqt4-dev libx11-dev

2. Download the source from here:

http://linux.softpedia.com/progDownload/LyX-Download-2149.html

Just double-click and drag out the directory inside. Put it anywhere you want! I'm messy, so I just left it on my desktop.

3. Open a terminal, and change to that directory. Type:

./configure

This should take a few minutes, and hopefully will end in success. If not, it should tell you which development libraries you are missing. With some searching in Synaptic, you should be able to find them. The package names are always something like lib...-dev.

4. Now, type this:

make

It took about 20 minutes on my system. When it's done, you can run your fresh build of LyX by clicking on lyx inside the src subdirectory. You can also simply drag this icon to your GNOME panel (or KDE equivalent) to automatically create a launcher.

When the Ubuntu LyX is finally working again, you can simply throw this directory to the trash. Or... you might want to keep it, just to have access to the latest and greatest LyX features. There's no harm at all in having both installs.

The version of lyx currently in Debian unstable reportedly fixes this problem. Once we get it building in Intrepid (currently it fails to build because of a problem with boost) then we can get it backported to Hardy.

I _don't_ have backported qt and I am suffering from this problem. Were qt updated also in main?

Finally, success. Using the source packages from Debian unstable (LyX 1.5.5-1), I was able to build an 8.04 package for 64-bit with Prevu, an automated backporting utility: https://wiki.ubuntu.com/Prevu

A side note, LyX 1.5.5-1 in Debian unstable was released yesterday (May 14), so it has not yet been synced with Intrepid (the previous version of LyX failed to build in Intrepid, but 1.5.5-1 should build successfully).

As far as I have seen, the problems have gone. I have qt4.4 from hardy backports (it's not disabled), and no problems.

I have built 64-bit packages which I can send to anyone who wants them (send me a private message to daradib on Ubuntu Forums). I don't know how to build 32-bit packages using Prevu on a 64-bit system, so you can make the package yourself by installing prevu (package in repositories), adding deb-src line for Debian Unstable, sudo apt-get update, and running the command prevu lyx.

You could also probably just install the Debian unstable (Sid) binary package for LyX (without modification), but I have not tried that.

I just checked, and it is not possible to install the Debian unstable (Sid) binary package for LyX without modification, because of a dependency-- libboost-filesystem1.34.1. So the prevu way is the solution, as it will modify the package's dependencies for Ubuntu.

LyX 1.5.5-1 should be synched into Intrepid and it should be officially backported in hardy-backports. If need be, I will open new bug reports.

I tried to install Lyx from source using checkinstall.

configure runs well
make runs well

sudo checkinstall doesn't work.

last lines with errorrs:

 /usr/bin/install -c -m 644 'lyx_1_0.py' '/usr/local/share/lyx/lyx2lyx/lyx_1_0.py'
 /usr/bin/install -c -m 644 'lyx_1_1.py' '/usr/local/share/lyx/lyx2lyx/lyx_1_1.py'
 /usr/bin/install -c -m 644 'lyx_1_1_5.py' '/usr/local/share/lyx/lyx2lyx/lyx_1_1_5.py'
 /usr/bin/install -c -m 644 'lyx_1_1_6_0.py' '/usr/local/share/lyx/lyx2lyx/lyx_1_1_6_0.py'
 /usr/bin/install -c -m 644 'lyx_1_1_6_3.py' '/usr/local/share/lyx/lyx2lyx/lyx_1_1_6_3.py'
 /usr/bin/install -c -m 644 'lyx_1_2.py' '/usr/local/share/lyx/lyx2lyx/lyx_1_2.py'
 /usr/bin/install -c -m 644 'lyx_1_3.py' '/usr/local/share/lyx/lyx2lyx/lyx_1_3.py'
 /usr/bin/install -c -m 644 'lyx_1_4.py' '/usr/local/share/lyx/lyx2lyx/lyx_1_4.py'
 /usr/bin/install -c -m 644 'lyx_1_5.py' '/usr/local/share/lyx/lyx2lyx/lyx_1_5.py'
 /usr/bin/install -c -m 644 'profiling.py' '/usr/local/share/lyx/lyx2lyx/profiling.py'
 /usr/bin/install -c -m 644 'test_parser_tools.py' '/usr/local/share/lyx/lyx2lyx/test_parser_tools.py'
Byte-compiling python modules...
lyx2lyx_version.py lyx2lyx_lang.py generate_encoding_info.py parser_tools.py LyX.py lyx_0_06.py lyx_0_08.py lyx_0_10.py lyx_0_12.py lyx_1_0.py lyx_1_1.py lyx_1_1_5.py lyx_1_1_6_0.py lyx_1_1_6_3.py lyx_1_2.py lyx_1_3.py lyx_1_4.py lyx_1_5.py profiling.py test_parser_tools.py
Byte-compiling python modules (optimized versions) ...
lyx2lyx_version.py lyx2lyx_lang.py generate_encoding_info.py parser_tools.py LyX.py lyx_0_06.py lyx_0_08.py lyx_0_10.py lyx_0_12.py lyx_1_0.py lyx_1_1.py lyx_1_1_5.py lyx_1_1_6_0.py lyx_1_1_6_3.py lyx_1_2.py lyx_1_3.py lyx_1_4.py lyx_1_5.py profiling.py test_parser_tools.py
make install-data-hook
make[4]: Betrete Verzeichnis '/var/tmp/install/lyx-1.5.5/lib/lyx2lyx'
chmod 755 /usr/local/share/lyx/lyx2lyx/lyx2lyx
chmod: Beim Setzen der Zugriffsrechte für „/usr/local/share/lyx/lyx2lyx/lyx2lyx“: No such file or directory
make[4]: *** [install-data-hook] Fehler 1
make[4]: Verlasse Verzeichnis '/var/tmp/install/lyx-1.5.5/lib/lyx2lyx'
make[3]: *** [install-data-am] Fehler 2
make[3]: Verlasse Verzeichnis '/var/tmp/install/lyx-1.5.5/lib/lyx2lyx'
make[2]: *** [install-am] Fehler 2
make[2]: Verlasse Verzeichnis '/var/tmp/install/lyx-1.5.5/lib/lyx2lyx'
make[1]: *** [install-recursive] Fehler 1
make[1]: Verlasse Verzeichnis '/var/tmp/install/lyx-1.5.5/lib'
make: *** [install-recursive] Fehler 1

**** Installation fehlgeschlagen. Breche Paket-Erzeugung ab.

Räume auf...OK

Auf Wiedersehen!

I don't know it that matters here but somehow related to lyx.

The Debian LyX maintainers strongly advise against using checkinstall for LyX, and they state that using checkinstall for LyX could have bad consequences. The best way it seems to fix LyX while keeping the packaging system intact (no make install) is to use the Prevu tool I mentioned in my comment above: https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/228067/comments/32.

Hello,
may someone please indicate me why this has been marked as fixed for Ubuntu?

I can understand that the Lyx develpers have fixed it in their repository. But Lyx didn't get updated to 1.5.5 in Ubuntu.
Therefore this is still to be solved.

Thanks in advance for your pointers.

It is not marked fixed in Ubuntu; the status is still confirmed. The bug has been marked fixed in LyX since the LyX developers have fixed the bug in their repository as you said.

To get this bug fixed in Ubuntu, the build of LyX in intrepid should be fixed first (currently it fails to build because of a problem with boost), then LyX 1.5.5-1 can be backported to hardy.

Thanks for this clarification.

The solution from "Emblem Parade" works great on my ubuntu x64.
Only after
4) make
you have to type
4) sudo make install

Than type on the Terminal: lyx

Can I say me too!
It does leave a directory on my desktop with 4,824 items (655 MB).
Since I've never done this before I'm going to leave it there.
It works fine [64 bit Hardy].
Thanks, Emblem!

BTW
I didn't do the sudo make install
But it works for me anyway.

Glad it works for you, guys!

"make install" is necessary only if you want to fully install it in your system. If you do that, I recommend that you remove the LyX you installed from the repositories first, otherwise the two versions will mix with each other.

I know it leaves a big directory... as I stated, my "solution" is meant to be temporary, until LyX is fixed in the repositories, in which you case you can delete that big directory and return exactly to where you were before, with no harm to your system.

1. Remove the packets from Synaptic
#lyx
#lyx-qt
#lyx-common

2. install the packets
#libqt4-core
#libqt4-dev
#libqt4-gui
#qt4-dev-tools
#qt4-qtconfig

3. download the latest source ftp://ftp.lyx.org/pub/lyx/stable/ and unpack

4. open terminal and go to the source directory

5. type in the terminal
#./configure --with-frontend=qt4 --with-qt-dir=/usr/share/qt4
#make (this may take up to 20 minutes)
#sudo make install

6. now start lyx by tipping lyx in the terminal

Now Lyx should work properly

A lot of people have been saying to run make install, but that is not a good solution IMHO. This would cause problems later on when the LyX package is updated and one wishes to install that package. If LyX is not removed via apt, conflicts will emerge. There are really only two reasonable temporary solutions.

1) ./configure and make (no sudo make install) and run LyX from the directory that has been created
2) build/install an updated package

Solution 2 is the better one, as it uses the excellent Ubuntu/Debian package management in place, but it does take a bit more effort.
It is not possible to directly install the Debian unstable (Sid) binary package for LyX without modification, because of a missing dependency: libboost-filesystem1.34.1. The way to do this is to use an automatic backporting utility called Prevu, which will modify the package's dependencies for Ubuntu.

Run the following commands in Terminal (Applications->Terminal) one at a time.

sudo -s
apt-get install prevu
prevu-init
echo "deb-src http://ftp.debian.org/debian/ sid main" >> /etc/apt/sources.list
apt-get update
prevu-update
exit
prevu lyx

The last step will take a while depending on the speed of your computer as LyX is compiled. When it is done, run Update Manager (System -> Administration -> Update Manager) and update LyX.

Alternatively I can give you the LyX packages I built with Prevu, but I have a 64-bit system and consequently have only 64-bit packages (I do not know how to build 32-bit packages with Prevu on a 64-bit system if that is possible).

Hi guys. I did what Cyrus Jones said on th procedure2. But I'm having problems updating my system. So I want to undo those operations because right now my system is very slooowwwww. Please help me....I don't want to reinstall ubuntu once again.

Emmanuel: the procedure suggested is to prepare a package, should have no effect on your system except if you ran out of disk space on your partition, check it (from the "computer" item in resources, or by entering "df -h /" in a terminal window) and eventually delete prevu files that are in /var/cache/prevu.

Emmanuel: To reverse the package preparation steps, you can uninstall the Prevu package, remove the Prevu directory, and remove Prevu's apt cache by following these steps:

1. Uninstall the Prevu package: sudo apt-get remove --purge prevu
2. Remove the Prevu directory: sudo rm -rf /var/cache/prevu
3. Remove Prevu's apt cache: sudo rm /var/cache/pbuilder/aptcache/*

Run the above commands in Terminal (Applications -> Terminal).

Thanks Guys!!!!!!

I've also been experiencing this bug in a nasty way...

I almost completed Cyrus Jones' method of backporting the debian unstable release, but I'm coming up with an error on the final step.

When I punch in:

$prevu lyx

I get an output of:

$ prevu lyx
I: Building against currently running distro: hardy

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Could not open file /var/lib/apt/lists/ftp.debian.org_debian_dists_sid_main_source_Sources - open (2 No such file or directory)
========================
Prevu Error: Fetching source package failed. Are you sure it exists?
Prevu encountered an error performing your build. The actual
error message may be further up in the scrollback before pbuilder
exited. Please look for a failed dependency or compile error in
the full output.

Any ideas?

I propose a different solution to upgrade to lyx 1.5.5 that may be easier and works very well:

add the debian sid software source.
in kubuntu adept -> manage repositories -> "third party software" -> add
deb http://ftp.de.debian.org/debian sid main

then many programs become updatable, hold on! do not update!
choose lyx and request it to be upgraded
in the "preview changes" you will see that some other three of four programs will also be upgraded due to dependencies
"apply changes"

then go back to the adept -> manage repositories -> "third party software"
and remove the cross from debian 'sid' (unstable) officially supported (you may also remove it altogether if you wish but is not necessary)

fetch updates return the usual list as you had before this procedure.

However, you now have lyx 1.5.5 installed properly with the required dependencies. When these programs become superseeded by a newer version in the usual channels, they will continue to be upgraded thus keeping the adept management tidy.

I also have the LyX crash problem on Hardy i386. Removing ~/.config/Trolltech* did not solve the problem. After compiling the sources (from apt-get source lyx) with --enable-debug, I got the following stack trace:
[New process 10045]
#0 0xb7fa8410 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fa8410 in __kernel_vsyscall ()
#1 0xb7010085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7011a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x0889bb4b in lyx::support::abort () at abort.cpp:25
#4 0x082754a1 in error_handler (err_sig=11) at LyX.cpp:835
#5 <signal handler called>
#6 0xb78950d9 in QPainter::worldMatrixEnabled () from /usr/lib/libQtGui.so.4
#7 0xb77f0f04 in QWidgetPrivate::paintSiblingsRecursive () from /usr/lib/libQtGui.so.4
#8 0xb77f0e17 in QWidgetPrivate::paintSiblingsRecursive () from /usr/lib/libQtGui.so.4
#9 0xb77f0e17 in QWidgetPrivate::paintSiblingsRecursive () from /usr/lib/libQtGui.so.4
#10 0xb77f0e17 in QWidgetPrivate::paintSiblingsRecursive () from /usr/lib/libQtGui.so.4
#11 0xb77f0e17 in QWidgetPrivate::paintSiblingsRecursive () from /usr/lib/libQtGui.so.4
#12 0xb77f0406 in QWidgetPrivate::drawWidget () from /usr/lib/libQtGui.so.4
#13 0xb7951e9d in ?? () from /usr/lib/libQtGui.so.4
#14 0xb7952627 in ?? () from /usr/lib/libQtGui.so.4
#15 0xb77f618f in QWidget::event () from /usr/lib/libQtGui.so.4
#16 0xb7b487e5 in QMainWindow::event () from /usr/lib/libQtGui.so.4
#17 0x0865bbb8 in lyx::frontend::GuiView::event (this=0x8e46838, e=0x8f066b0) at GuiView.cpp:720
#18 0xb779ec0c in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4
#19 0xb77a3898 in QApplication::notify () from /usr/lib/libQtGui.so.4
#20 0x08647428 in lyx::frontend::GuiApplication::notify (this=0x8bd0c40, receiver=0x8e46838,
    event=0x8f066b0) at GuiApplication.cpp:256
#21 0xb756b6a9 in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4
#22 0xb756ca59 in QCoreApplicationPrivate::sendPostedEvents () from /usr/lib/libQtCore.so.4
#23 0xb756cc7d in QCoreApplication::sendPostedEvents () from /usr/lib/libQtCore.so.4
#24 0xb7596bcf in ?? () from /usr/lib/libQtCore.so.4
#25 0xb6f19bf8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#26 0xb6f1ce5e in ?? () from /usr/lib/libglib-2.0.so.0
#27 0xb6f1d3ac in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#28 0xb7596f98 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4
#29 0xb78321b5 in ?? () from /usr/lib/libQtGui.so.4
#30 0xb756a92d in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4
#31 0xb756aabd in QEventLoop::exec () from /usr/lib/libQtCore.so.4
#32 0xb756cd3d in QCoreApplication::exec () from /usr/lib/libQtCore.so.4
#33 0xb779e567 in QApplication::exec () from /usr/lib/libQtGui.so.4
#34 0x08280577 in lyx::LyX::exec (this=0xbfe4c90c, argc=@0xbfe4c940, argv=0xbfe4c9c4) at LyX.cpp:480
#35 0x0806bed0 in main (argc=1, argv=0x0) at main.cpp:48

Since I did not have the time to further track down the problem, I have finally removed the lyx binary package, downloaded the latest 1.5.5 sources from http://www.lyx.org and installed the self-compiled binaries. This works for my system, without any changes to Qt4, etc.

Hi Thomas,

read the thread carefully. You just have to disable the backports
repositories and reinstall the packages mentioned previously ;)
No recompile necessary!

Greets Axel

Am Donnerstag, den 19.06.2008, 10:14 +0000 schrieb Thomas Dreibholz:
> I also have the LyX crash problem on Hardy i386. Removing ~/.config/Trolltech* did not solve the problem. After compiling the sources (from apt-get source lyx) with --enable-debug, I got the following stack trace:
> [New process 10045]
> #0 0xb7fa8410 in __kernel_vsyscall ()
> (gdb) bt
> #0 0xb7fa8410 in __kernel_vsyscall ()
> #1 0xb7010085 in raise () from /lib/tls/i686/cmov/libc.so.6
> #2 0xb7011a01 in abort () from /lib/tls/i686/cmov/libc.so.6
> #3 0x0889bb4b in lyx::support::abort () at abort.cpp:25
> #4 0x082754a1 in error_handler (err_sig=11) at LyX.cpp:835
> #5 <signal handler called>
> #6 0xb78950d9 in QPainter::worldMatrixEnabled () from /usr/lib/libQtGui.so.4
> #7 0xb77f0f04 in QWidgetPrivate::paintSiblingsRecursive () from /usr/lib/libQtGui.so.4
> #8 0xb77f0e17 in QWidgetPrivate::paintSiblingsRecursive () from /usr/lib/libQtGui.so.4
> #9 0xb77f0e17 in QWidgetPrivate::paintSiblingsRecursive () from /usr/lib/libQtGui.so.4
> #10 0xb77f0e17 in QWidgetPrivate::paintSiblingsRecursive () from /usr/lib/libQtGui.so.4
> #11 0xb77f0e17 in QWidgetPrivate::paintSiblingsRecursive () from /usr/lib/libQtGui.so.4
> #12 0xb77f0406 in QWidgetPrivate::drawWidget () from /usr/lib/libQtGui.so.4
> #13 0xb7951e9d in ?? () from /usr/lib/libQtGui.so.4
> #14 0xb7952627 in ?? () from /usr/lib/libQtGui.so.4
> #15 0xb77f618f in QWidget::event () from /usr/lib/libQtGui.so.4
> #16 0xb7b487e5 in QMainWindow::event () from /usr/lib/libQtGui.so.4
> #17 0x0865bbb8 in lyx::frontend::GuiView::event (this=0x8e46838, e=0x8f066b0) at GuiView.cpp:720
> #18 0xb779ec0c in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4
> #19 0xb77a3898 in QApplication::notify () from /usr/lib/libQtGui.so.4
> #20 0x08647428 in lyx::frontend::GuiApplication::notify (this=0x8bd0c40, receiver=0x8e46838,
> event=0x8f066b0) at GuiApplication.cpp:256
> #21 0xb756b6a9 in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4
> #22 0xb756ca59 in QCoreApplicationPrivate::sendPostedEvents () from /usr/lib/libQtCore.so.4
> #23 0xb756cc7d in QCoreApplication::sendPostedEvents () from /usr/lib/libQtCore.so.4
> #24 0xb7596bcf in ?? () from /usr/lib/libQtCore.so.4
> #25 0xb6f19bf8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
> #26 0xb6f1ce5e in ?? () from /usr/lib/libglib-2.0.so.0
> #27 0xb6f1d3ac in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
> #28 0xb7596f98 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4
> #29 0xb78321b5 in ?? () from /usr/lib/libQtGui.so.4
> #30 0xb756a92d in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4
> #31 0xb756aabd in QEventLoop::exec () from /usr/lib/libQtCore.so.4
> #32 0xb756cd3d in QCoreApplication::exec () from /usr/lib/libQtCore.so.4
> #33 0xb779e567 in QApplication::exec () from /usr/lib/libQtGui.so.4
> #34 0x08280577 in lyx::LyX::exec (this=0xbfe4c90c, argc=@0xbfe4c940, argv=0xbfe4c9c4) at LyX.cpp:480
> #35 0x0806bed0 i...

Hi Axel,

since the problem was LyX only, I preferred to keep my sources.list as it is and only update LyX. This way, I also got the latest version (1.5.5) of LyX. Of course this is not the fastest solution, since compiling LyX on my machine takes about 40 minutes.

Regards
Thomas

Please Bug #242648, a backport request for LyX 1.5.5-1 in Ubuntu Hardy that will fix this bug.

This appears to be fixed now with the release of lyx 1.5.5-1 into the backports repository.

The bug still exists in Intrepid as the source package of LyX 1.5.5-1 in Intrepid failed to build (apparently because of a problem with the boost dependency). However, a related bug, Bug #242648, was fixed since LyX 1.5.5-1 (with no changes) was uploaded to Hardy Backports and binary packages were successfully built.

Please fix this bug in Intrepid by successfully building the source package.

This bug was fixed in Intrepid on July 11 with the successful building of binary packages of LyX 1.5.5-1. The same bug in Ubuntu 8.04 Backports (Bug #242648), was fixed on July 2.