Hello. euh.. let's make it simple. We use inkscape since the beginning of the project (we were on sodipodi and moved with the fork - a svg compliance choice). we decided to upgrade to inkscape 0.40 yesterday on some machines FedoraCore1. we grab the static package. it claimed for a gtk2-2.4 (we grab a GTK2-2.4.0) (was for fedora core 2) and a atk 1.6 and pango 1.4.0 ok was it was a bad idea fedora core 2.
we rpm -uvh everything without warning and inkscape started and workd fine. but when we restarted X wouldn' start : a X server already started on 0: and /var/log/messages says : __________ init : open (dev/pts/0) : no such file or directory modeprob : modeprobe can't locate module fb0 / fb1/ fb2 etc... _______________________ we google-ed a little and it appears to be a "kernel' stuf ? (taking fc2 rpm for a fc1 was really a bad choice ! !)
So what we can do is
1) to go back to previous state (gtk2-2.2). but that means no inkscape 0.40 2) upgrade to FC2/3 (we do not have time to do it now) 3 ) ask for help here, there are so much competence, maybe a ln -s could solve the probleme. (linking dev/pts/O to something could work ?)
thanks
On Tue, Dec 14, 2004 at 02:25:18PM +0100, herve couvelard wrote:
but when we restarted X wouldn' start : a X server already started on 0: and /var/log/messages says : __________ init : open (dev/pts/0) : no such file or directory modeprob : modeprobe can't locate module fb0 / fb1/ fb2 etc... _______________________ we google-ed a little and it appears to be a "kernel' stuf ? (taking fc2 rpm for a fc1 was really a bad choice ! !)
check your /var/log/XFree*log files. There may be hints in there. Have you done a full reboot? Did you upgrade parts of X11 along with the other stuff? I worry you may be in a pretty serious jam.
- upgrade to FC2/3 (we do not have time to do it now)
You may be forced to this, depending on the state of your system.
Good luck, I hope you do better than I did. I stopped using RedHat when I tried to upgrade from rh8 to rh9. Totally destroyed my system. Been using Debian ever since.
On Tue, 14 Dec 2004 14:25:18 +0100, herve couvelard <herve.couvelard@...26...> wrote:
Hello. euh.. let's make it simple. We use inkscape since the beginning of the project (we were on sodipodi and moved with the fork - a svg compliance choice). we decided to upgrade to inkscape 0.40 yesterday on some machines FedoraCore1. we grab the static package. it claimed for a gtk2-2.4 (we grab a GTK2-2.4.0) (was for fedora core 2) and a atk 1.6 and pango 1.4.0 ok was it was a bad idea fedora core 2.
we rpm -uvh everything without warning and inkscape started and workd fine. but when we restarted X wouldn' start : a X server already started on 0: and /var/log/messages says : __________ init : open (dev/pts/0) : no such file or directory modeprob : modeprobe can't locate module fb0 / fb1/ fb2 etc... _______________________ we google-ed a little and it appears to be a "kernel' stuf ? (taking fc2 rpm for a fc1 was really a bad choice ! !)
So what we can do is
- to go back to previous state (gtk2-2.2).
but that means no inkscape 0.40 2) upgrade to FC2/3 (we do not have time to do it now) 3 ) ask for help here, there are so much competence, maybe a ln -s could solve the probleme. (linking dev/pts/O to something could work ?)
thanks
I had the same problem but on Ubuntu Warty install when I attempted to get inkscape .40 from the Hoary development stream.
For me I upgraded some more packages like gdm possibly ubuntu-base and whatever other packages that brought in. Sorry, I can't be specific, I just selectively installed packages until the problem went away. I do know that I didn't have to upgrade many packages to resolve the problem. GDM might have been the key package. At the same time I was attempting to resolve problems with hotplug and a webcam so I was upgrading HAL and gnome-volume-manager and other related packages.
Hope this helps,
ok i tried in upgrading gdbm -> same problems So i downgrade to gtk2-2.2 / inkscape 0.38 (rpm -Uvh --force --nodeps) and everything return to normal.
i guess that there is a way to do it, because _before_ the reboot everything was fine. so something happens during reboot that is not necessary. (i tried ro rebuild the gtk2-2.4.0..src.rpm but no succes) too bad.. Nobody here succeed on a fedora1 with inkscape 0.40 ?
if even kees an Robert can't help, well, i am not able to do it myself
thanks a lot hervé
Robert Crosbie wrote:
On Tue, 14 Dec 2004 14:25:18 +0100, herve couvelard <herve.couvelard@...26...> wrote:
Hello. euh.. let's make it simple. We use inkscape since the beginning of the project (we were on sodipodi and moved with the fork - a svg compliance choice). we decided to upgrade to inkscape 0.40 yesterday on some machines FedoraCore1. we grab the static package. it claimed for a gtk2-2.4 (we grab a GTK2-2.4.0) (was for fedora core 2) and a atk 1.6 and pango 1.4.0 ok was it was a bad idea fedora core 2.
we rpm -uvh everything without warning and inkscape started and workd fine. but when we restarted X wouldn' start : a X server already started on 0: and /var/log/messages says : __________ init : open (dev/pts/0) : no such file or directory modeprob : modeprobe can't locate module fb0 / fb1/ fb2 etc... _______________________ we google-ed a little and it appears to be a "kernel' stuf ? (taking fc2 rpm for a fc1 was really a bad choice ! !)
So what we can do is
- to go back to previous state (gtk2-2.2).
but that means no inkscape 0.40 2) upgrade to FC2/3 (we do not have time to do it now) 3 ) ask for help here, there are so much competence, maybe a ln -s could solve the probleme. (linking dev/pts/O to something could work ?)
thanks
ok i tried in upgrading gdbm -> same problems So i downgrade to gtk2-2.2 / inkscape 0.38 (rpm -Uvh --force --nodeps) and everything return to normal.
You're overwriting GTK+ 2.2 with GTK+ 2.4, this most likely your problem.
Many, many things on your system depend on GTK+ 2.2. GTK+ versions are parallel installable, but you're not parallel installing different GTK+ versions... Maybe there is a gtk24-2.4 package out there you can find and install.
If nothing else, you can try doing 'rpm -ivh gtk2-2.4*' instead of -Uvh. This way you'll have both packages installed at the same time. The package installed last will likely overwrite any binaries and documentation, etc. But the shared libraries should be named in such a way as to not overwrite each other.
On my FC3 systems, for example, I have gtkmm2 and gtkmm24 installed. But in cases where packages aren't so conviently named, sometimes your only option is to use -ivh instead of -Uvh. (I've had to do this with curl several times.)
i guess that there is a way to do it, because _before_ the reboot everything was fine. so something happens during reboot that is not necessary.
Before the reboot, the old GTK+ 2.2 libraries are probably in memory in use by other running programs, even though they no longer exist on disk. Rebooting flushes memory, and the memory of the programs using that memory... And then they call crap out because they can't find the .so files they were compiled against.
That's my edumacated guess, anyways.
(i tried ro rebuild the gtk2-2.4.0..src.rpm but no succes) too bad.. Nobody here succeed on a fedora1 with inkscape 0.40 ?
If you compile GTK+ 2.4 and gtkmm 2.4 and the rest of the stack from source, install it all into /usr/local (or /opt, if you know a bit more about what you're doing and want better seperatation and/or deletability), you shouldn't have any problems at all. (Well, that is, except for the problem of compiling from source. *grin*)
If you can't find a way to parallel install gtk2 RPMs, then compiling from source may be your only other option.
On Tue, 2004-12-14 at 20:13 -0600, Derek P. Moore wrote:
ok i tried in upgrading gdbm -> same problems So i downgrade to gtk2-2.2 / inkscape 0.38 (rpm -Uvh --force --nodeps) and everything return to normal.
You're overwriting GTK+ 2.2 with GTK+ 2.4, this most likely your problem.
No, it really shouldn't be. Modulo a bug that was in a few GTK+-2.4 versions (and is fixed now), anything built against an older GTK+-2.x version should be able to use a more recent GTK+ version at runtime.
If nothing else, you can try doing 'rpm -ivh gtk2-2.4*' instead of -Uvh. This way you'll have both packages installed at the same time. The package installed last will likely overwrite any binaries and documentation, etc. But the shared libraries should be named in such a way as to not overwrite each other.
No. They are not parallel-installable since the ABI has been expanded but not broken. I believe that the new package will completely and utterly clobber the old one.
On my FC3 systems, for example, I have gtkmm2 and gtkmm24 installed. But in cases where packages aren't so conviently named, sometimes your only option is to use -ivh instead of -Uvh. (I've had to do this with curl several times.)
And this is rather unrelated to what's going on with the core GTK packages. The C++ language bindings, gtkmm and friends, broke ABI between 2.2 and 2.4 and were thus made parallel installable, that's why people typically make packages such as gtkmm20-2.2.x and gtkmm24-2.4.x etc. Even the gtkmm20 packages run against newer versions of GTK+ though. The GTK+ developers are committed to binary compatibility until GTK+ 3 is released. (And at that point, GTK+ 2 and 3 packages will be parallel installable.) [By the way, the API/ABI change between gtkmm 2.2 and 2.4 is completely unrelated to the underlying C++ API change between GCC 3.3 and 3.4, and the corresponding changed libstdc++.]
Unfortunately I'm afraid that something significantly more sinister is going on, but I can't see what.
Herve: you really only upgraded the GTK+ and glib packages? And by the way, I presume that it was GDM, not gdbm, you installed on Robert's suggestion? gdbm wouldn't be related to this, but GDM could be.
Alternatively, you might have better luck rebuilding the FC2 SRPMs on FC1 and installing the resulting binaries.
Good luck, Per
Quoting Per Bjornsson <perbj@...604...>:
You're overwriting GTK+ 2.2 with GTK+ 2.4, this most likely your problem.
No, it really shouldn't be. Modulo a bug that was in a few GTK+-2.4 versions (and is fixed now), anything built against an older GTK+-2.x version should be able to use a more recent GTK+ version at runtime.
I know it shouldn't be the problem, but that's what it looks like it is.
If he downgrades gtk2 and things work again, then the problem seems to be pretty isolated to me.
No. They are not parallel-installable since the ABI has been expanded but not broken. I believe that the new package will completely and utterly clobber the old one.
They are indeed parallel-installable. Any good library these days is parallel installable with any of its previous versions. That's why ELF shared object files have major and minor number, as I'm sure we're all aware. The distribution packaging itself may not be explicitly parallel-installable, but the underlying files certainly are.
Have a look at the Files section for:
the most current gtk2 from FC3 http://fr2.rpmfind.net/linux/RPM/fedora/updates/3/i386/gtk2-2.4.14-1.fc3.i38...
and the most current gtk2 from FC1 http://fr2.rpmfind.net/linux/RPM/fedora/updates/1/i386/gtk2-2.2.4-10.i386.ht...
... they're parallel-installable.
A few binaries will be overwritten, and half of the documentation will be overwritten, but all the important files (the shared object files) will be safe.
On my FC3 systems, for example, I have gtkmm2 and gtkmm24 installed. But in cases where packages aren't so conviently named, sometimes your only option is to use -ivh instead of -Uvh. (I've had to do this with curl several times.)
And this is rather unrelated to what's going on with the core GTK packages.
That is indeed why gtkmm packages are explicitly parallel-installable and gtk2 packages are not. But parallel-installability really has to do with pkg-config, the autotools, and ELF.
Whereas gtk2's packages are not explicitly parallel-installable, because in theory things should behave properly, they are indeed still parallel-installable via 'rpm -ivh' instead of 'rpm -Uvh'.
I'm not saying parallel-installing gtk2.2 and gtk2.4 will solve his problem, but it couldn't hurt him to give it a shot. It's solved my problems with other libraries in similar situations.
Herve has also already said that he's rebuilt the gtk2-2.4 SRPM from FC2 for his FC1 system. He would most certainly have problems using the binaries from FC2, but he said he's rebuilt the packages...
In the end, I'm just as stumped as you, Per. But at least Herve can safely attempt parallel-installing gtk2 2.2 and 2.4, and see if that doesn't help. He can always '-e' 2.4 and '-Uvh --oldpackage' 2.2 and be back to where he started.
Herve has also already said that he's rebuilt the gtk2-2.4 SRPM from FC2 for his FC1 system. He would most certainly have problems using the binaries from FC2, but he said he's rebuilt the packages...
Oh, wait!
Herve says, "(i tried ro rebuild the gtk2-2.4.0..src.rpm but no succes)".
And Per, you said that early versions of GTK+ 2.4 had a bug that kept binaries compiled against 2.2 from working. And, well, Herve said he rebuild 2.4.0, that's as early as you can get.
Herve, try rebuilding gtk2 SRPM from Fedora Core 2 Updates. See:
http://fr2.rpmfind.net/linux/RPM/fedora/updates/2/i386/gtk2-2.4.14-1.fc2.i38...
If Per is right, rebuilding the source RPM from this update might solve your problems!
On Wed, 2004-12-15 at 00:31 -0600, Derek P. Moore wrote:
And Per, you said that early versions of GTK+ 2.4 had a bug that kept binaries compiled against 2.2 from working. And, well, Herve said he rebuild 2.4.0, that's as early as you can get.
I'm not sure which versions were affected (I actually think that the ABI breakage might have been introduced in a bugfix release...), and the breakage was rather subtle - it's unlikely that everything would go down the tubes because of it as far as I have understood.
It's perfectly possible that GDM, the display manager, does something fishy, and Herve in fact said that he updated "gdbm" which is something else entirely so updating GDM might be the key. (Likely this was just a typo though, so I still find it all very confusing.)
Herve, try rebuilding gtk2 SRPM from Fedora Core 2 Updates. See:
http://fr2.rpmfind.net/linux/RPM/fedora/updates/2/i386/gtk2-2.4.14-1.fc2.i38...
If Per is right, rebuilding the source RPM from this update might solve your problems!
Well, with some luck it might do it, for whatever reason... It's worth a shot!
-Per
And Per, you said that early versions of GTK+ 2.4 had a bug that kept binaries compiled against 2.2 from working. And, well, Herve said he rebuild 2.4.0, that's as early as you can get.
Herve, try rebuilding gtk2 SRPM from Fedora Core 2 Updates. See:
http://fr2.rpmfind.net/linux/RPM/fedora/updates/2/i386/gtk2-2.4.14-1.fc2.i38...
If Per is right, rebuilding the source RPM from this update might solve your problems!
i tried to parallele install gtk2-2.4.0 with gtk2-2.2 well.. it succed in installing maybe --force helped (i know that's not funny ;-) ) but no rebboot.. : the only thing i did is installing gtk2-2.4 so i came back with -e gtk2-2.4 -Uvh --force -oldpackage gtk2-2.2.. i could not have gtk2-2.4.14 because it needs libxinerama -> seems to depend on Xorg and we are still with XFree86 tha's why i took 2.4.0 but could'nt rebuild it (lack of ft2build.h ? in freetype.h).
Too bad. Anyway, i thing that the major problem is that FC1 is kernel 2.4 and XFREE and FC2 is kernel 2.6 and Xorg. Thas is realy fun because i succed with gimp2.0 with some fedoracore2 packages. well... we'll be with inkscape 0.38 untill a real new install FC3
hervé
On Tue, 14 Dec 2004 18:34:34 +0100, herve couvelard wrote:
ok i tried in upgrading gdbm -> same problems So i downgrade to gtk2-2.2 / inkscape 0.38 (rpm -Uvh --force --nodeps) and everything return to normal.
This may be a variant of the GObject changes - when you log out does the logout proceed normally, or does it hang before X shuts down correctly?
I suspect what is happening is that a known backwards compatibility issue the GObject maintainer refused to fix is deadlocking the GNOME logout screen at some point, but the system shutdown has already started. This means X doesn't shut down correctly as it's grabbed by GNOME, meaning it'll be sent SIGKILL just before the system halts.
Next time the system starts up, the dead X socket is still on the filing system so preventing the new X server from starting.
Total stab in the dark but this is my guess.
thanks -mike
well, i'm realy impress with such knowledge. would that means it would be possible to hugly-hugly kill dead X socket before starting a new one ? or maybe some magic things to do after instal GTK2-2.4 ?
how can it be seen a logout proceded normally ? in /var/log/messages ? because shutdown messages are 'normal'.
in var log message when X won't start : it says : init(open(/dev/pts/0) No such file or directory, i understood from google that pts where kernel stuff (could be possible as fc1 is kerne 2.4 and gtk2-2.4 is for fC2 - kernel 2.6).
hervé
This may be a variant of the GObject changes - when you log out does the logout proceed normally, or does it hang before X shuts down correctly?
I suspect what is happening is that a known backwards compatibility issue the GObject maintainer refused to fix is deadlocking the GNOME logout screen at some point, but the system shutdown has already started. This means X doesn't shut down correctly as it's grabbed by GNOME, meaning it'll be sent SIGKILL just before the system halts.
Next time the system starts up, the dead X socket is still on the filing system so preventing the new X server from starting.
Total stab in the dark but this is my guess.
thanks -mike
participants (6)
-
Derek P. Moore -
herve couvelard -
Kees Cook -
Mike Hearn -
Per Bjornsson -
Robert Crosbie