SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Even if I installed font-adobe-utopia-type1-X11R7.0-1.0.1 manually I ended with the same error. So I run build-from-tarballs.sh script with -n optin (-n : do not quit after error; just print error message) and solve the problem with mentioned font after whole build will be done
The other option would be to build the font manually then remove the file font-adobe-utopia-type1-X11R7.0-1.0.1.tar.bz2 so when you rerun the build-from-tarballs.sh script it will see the package is missing and just skip that package. If you look in the font directory (/usr/X11R7/lib/X11/fonts/Type1) you should have something like this:
The error I described above has appeared with other 7 fonts. All problematic are from TTF, Type1 ant OTF. What's interesting is fact those fonts are installed in their directories in /usr/X11R7/lib/X11/fonts! Even fonts.dir and fonts.scale are correctly created. I really don't understand what happened.
Now I get back to /bin/bash's first post. How about to rename /usr/X11R7 in /usr/X11R6 having backuped old /usr/X11R6? I think this could avoid creating symlinks which are pointed into /usr/X11R6 and necessary changes in xorg.conf. Am I wrong?
Now I get back to /bin/bash's first post. How about to rename /usr/X11R7 in /usr/X11R6 having backuped old /usr/X11R6? I think this could avoid creating symlinks which are pointed into /usr/X11R6 and necessary changes in xorg.conf. Am I wrong?
I'm sure there are many different ways to accomplish the same thing I posted in the first post. I have tried this several different ways myself. The important thing is to keep a backup so you can restore if something goes wrong.
One thing I have noticed is when you use the --prefix=/usr/X11R7 the new Xorg server now looks in /usr/X11R7 tree for certain files. For example it looks in /usr/X11R7/lib/X11 instead of /etc/X11 for alot of configuration files.
You have to download MesaLib package from extras, untar it f.e. int /tmp/Mesa-6.4.1 and run build-from-tarballs.sh scrip with -m /tmp/Mesa-6.4.1 option.
I think, after reading thru all these posts on this issue, that I may wait until R7 is compiled CORRECTLY and packaged for Slackware before I will even think of trying the upgrade. The little workarounds, symlinks, etc., kind of remind me of forcing Windows to work.
I think, as I said, I'll wait until it is stable enough, and configured correctly for Slackware, before I'll try it.
The little workarounds, symlinks, etc., kind of remind me of forcing Windows to work.
Not really. If we were dealing with windows this upgrade would cost us 100-200 bucks. There would be 1 binary package for every x86 computer in the world. So the idea of forcing it to work is out of the question, you are at Microsofts mercy there. Most likely this would break many apps that Microsoft doesn't like or hasn't been able to buy out yet. As of yet I have not found a single app that X11R7 has broken. You would need to upgrade your computer to be compatible with with this latest Micronopoly upgrade, but I didn't upgrade for this X11R7 update.
Look for slackware-current/slackware/x/x11-6.9.0-i486-1.tgz
This is x11-7.0 just in the old format 1 single package as opposed to the new modular format of X11R7.0.
I wanted to upgrade from the x11R6.8.2 in 10.2, but I need to have a "build tree" in order to compile my video driver (unichrome.sourceforge.net). In the past I have installed x11 from source packages and that gave me a build tree in /tmp/x11-build/. If I install the x11-devel package, will that give me a "build tree" and where is it? Here is a quote from the video driver README:
Quote:
Building The Unichrome Projects drivers for your X version:
1.1) Against a full X tree: This requires that a sufficiently built X tree is present . . . From the top level run # xmkmf <path_to_xc>
2) Modular X: Building against modular is a breeze. You should have everything installed for building drivers if and when you want to. . . # ./autogen.sh --prefix=<...>
Basically, which choice is best: install x11-devel with the updated packages, download the source packages and run the build script, or build from scratch?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.