scoonma

I don't know wether Anjuta integrates well into KDE, but it's written in and mainly for GTK/Gnome. You can use both KDE and GNOME (on user level), but when developing apps, you'll better decide which way to go (i.e. use gtk or qt libraries for desktop progs).

GNOME deeply relies on the pango lib, so you likely won't get along without when choosing the GNOME path. If you'd rather tend to work in the KDE realm, then maybe better choose a different IDE? Here's KDevelop:

http://www.kdevelop.org/

Jolly hacking,

scoonma

Hm. Control centers are convenient for users who are new to Linux or Computers in general. Personally, the design of MCC was one of the aspects to choose Mandriva (instead of SuSE or RedHat). If you want to dig deeper into the system, you may leave it aside by time (but you don't have to). This makes complexity of a system handy. OTOH, there are many approaches. One could also think of an adjusted version based on webmin for sytem management, for example.

If you prefer system control in very detail, you'll presumably leave topmost level management tools aside. So in the end it's up to your needs. How much time are you willing to spend for control tasks?

Hi scaff,

did you change some settings of your system before the error occurred? To encircle the faulty condition it would help if we knew... You don't have be scrupulous about it - most of us here on board presumably stumbled over a kernel panic at least once. :-)

Hi jgw,

can't see why you shouldn't go on with Anjuta. GNOME or KDE ... well, that's more like a matter of taste. Although Gtk and GNOME have evolved together. What is the name of the package you're missing?

Howdy folks,

today I had to install a recent version of the proprietary acrobat reader by Adobe. By now evince is not letting one fill out forms in pdf-documents. So I downloaded the latest version (7.0.8) for Linux. However, after installing the actual "acroread" command constantly fails with an syntax error infinite loop. The problem is not caused by Mandriva or shell selection, but lies within the "/usr/bin/acroread" script itself. After some searching I was lucky to find the solution in this somewhat lengthy thread:

http://www.ubuntuforums.org/archive/index.php/t-221769.html

The gtk detection boils out.

Change line 421 in /usr/bin/acroread:
old:

echo $mfile| sed 's/libgtk-x11-\([0-9]*\).0.so.0.\([0-9]\)00.\([0-9]*\)\|\(.*\)/\1\2\3/g'

new:

echo $mfile| sed 's/libgtk-x11-\([0-9]*\).0.so.0.\([0-9]\)000.\([0-9]*\)\|\(.*\)/\1\2\3/g'

Maybe someone is finding this useful.

Cheers,

scoonma

Hi Stepniac,

I don't wish it to your CDs, even more as you've bought the software, but did you check wether you can see scratches on the surface? Defects both on top and bottom side may cause the disk go unreadable. I once was lucky with the experiment on an old, really scratchy and thus dysfuntional install CD: Just duplicated it with k3b (clone option deactivated), and the copy worked fine as the master did before. Seemed to me that some error correction did actually work.

HTH,

scoonma

Hi jagwah,

you wrote:

I started trying to see if I could compile one myself with the Man2007 rc1, but I needed to install other stuff before I could even begin, and wasn't real sure where to get the packages from for 2007, so I thought I would just let it be until it was actually released and things were set up. Plus I don't really know what to expect when/if I did actually get to compiling the kernel for myself, is it all selfexplanatory, or would I be just lost?

It *is* self-explanatory, but when you go through the procedure the first time, you'll have to read at least some manuals carefully and be willing to spend time and possibly some unsuccessfull attempts. However, it should be possible just to change the timer resolution, and leave any other option untouched. Thus you'd be more safe to get a working kernel; compared to trying a build, which perfectly suits your hardware and need. This may be alluring when you see the little world of options of its own, of which you likely do not to even know some or many names. This is the place of core access, and you can finetune your system to a level you decide on your own, near to it's physical maximum and personal liking. But the higher the level, the more reading and real learning is involved. Not everyone does like it or is able to take the time.

However, if you want to take basic steps on this road, take a free weekend (at least several hours) and consider the following reduced info:

1) Read the FAQs of this forum regarding kernel compilation

2) Install proper kernel sources (i.e. a stable version out of contrib repository patched to use with Mandriva, *not* the most actual from kernel.org ;-)

3) Do a root login on a terminal window and change directory to /usr/src/linux-2.x.y.z, with x.y.z reflecting the kernel version you're using (check with uname -a)

4) Read and try to understand the README file residing here as good as you can

5) Enter Documentation folder below, read and understand the Changes file here.

6) Install missing software being mentioned

7) Take the actual steps to build the kernel:

- Do "make menuconfig" for instance and change desired options (you find the option to set Timer Frequency at the bottom of the "Processor type and feature" menu).

- Do "make install" && "make modules_install" (this is for a 2.6.17 series kernel)

When everything went allright (you can ignore warnings, but not errors!), reboot and your new kernel.

One thing is for sure, I need a kernel with a higher timer resolution, so what is the best way to go?

:-) Which way is *best* you have to decide on your own. If you want to learn about your system from the inside, you can take the long road described above.

If you want to take a shortcut, you can use a 2.6.17.11-mm-desktop-2mdv kernel. Just checked it has the 1000Mhz option enabled by default. But this is the 32bit version (i.e. i586). Don't know about x86_64.

Cheers,

scoonma

Anyhow, Windows needs to be installed on its own partition which MUST be at the beginning of the drive.

No. :-) I've managed to get the winthing installed and working on a different partition. However, it must be a primary one, extended (i.e. logical) does not work.

I've heard it's possible to install Windows using VMware (a virtualization app with a different concept as wine). It's not completely free, but you can install a server version.

http://www.vmware.com/

HTH,

scoonma

My interpretation of the logfile is that package QtCurve does not get built because of the reason which is also mentioned in the log:

configure:3805: checking for g++
configure:3834: result: no
configure:3805: checking for c++
configure:3834: result: no
configure:3805: checking for gpp
configure:3834: result: no
configure:3805: checking for aCC
configure:3834: result: no
configure:3805: checking for CC
configure:3834: result: no
configure:3805: checking for cxx
configure:3834: result: no
configure:3805: checking for cc++
configure:3834: result: no
configure:3805: checking for cl
configure:3834: result: no
configure:3805: checking for FCC
configure:3834: result: no
configure:3805: checking for KCC
configure:3834: result: no
configure:3805: checking for RCC
configure:3834: result: no
configure:3805: checking for xlC_r
configure:3834: result: no
configure:3805: checking for xlC
configure:3834: result: no
configure:3847: checking for C++ compiler version
configure:3850: g++ --version </dev/null >&5
./configure: line 3851: g++: command not found
configure:3853: $? = 127
configure:3855: g++ -v </dev/null >&5
./configure: line 3856: g++: command not found
configure:3858: $? = 127
configure:3860: g++ -V </dev/null >&5
./configure: line 3861: g++: command not found
configure:3863: $? = 127
configure:3866: checking whether we are using the GNU C++ compiler
configure:3890: g++ -c conftest.cc >&5
./configure: line 3891: g++: command not found
configure:3896: $? = 127

Presumed the rpm is fine, configure is looking for a c++ compiler which is simply not installed. Which compiler are you using?

Otherwise I'd take care of the QtCurve source: Is it a package on it's own? Are up-to-date devel packages available?

I can't see why different compiler versions (tarball/system) should cause an error here. A match is rather an exception than normal when building applications. (However, differences in major version, building a kernel or glibc may not to be ignored.) At least this is what experiences tell me. Am I wrong with that?

Hi DarkFoss,

thx for making this clear. Yes, standard driver for cards with our chip series used to be radeon or ati respectively, inserting the radeon module when loading. This is at least what I've understood how the drivers work by now.

Don't worry about your information not precise enough. Maybe I did not explain this right (or some language shortcoming/adjustment?): Me thinks I'm quite understanding your description semantically, but what I did not understand is why your config is working from a technical point of view.

The fglrx driver is not like the xorg ones, i.e. being modular, but a single one for a large number of ATI cards with similar video chips. Besides your card belonging to a newer generation than mine and thus more capable, your config was the most close to mine I could find until now. So I copied it and adapted where needed. Maybe the difference of inbuilt rendering chips (here is R350) is the reason why you can run the fglrx/Xgl combination and me not. Knowing wether this is the case would at least calm my curiosity. :-)

Cheers,

scoonma

Hi Lando,

seems to be there's a misunderstanding about the purpose of lilo:

Lilo does *not* show partitions. The boot entries are not identical to partition names. When installing lilo, it checks wether you have windows formatted partitions. If it finds one or more, it creates a boot entry for windows, too. By this you can use linux but do not loose windows.

If you reformatted your second HD completely, you will loose *all* data stored here! With your config, that would be all of linux and your windows data. Are you really sure you want to do this? Keep in mind that windows registry and probably desktop links point to data on your second HD, so you're likely ruining your desktop, though the main system may stay somewhat usable.

If you only want to get rid of linux, fdisk /mbr is a method to kick away lilo out of the master boot record, when installed here. Afterwards you could boot into win and reformat the linux partitions.

After all, it would be easier if you help if we knew what you want to achieve. What is your aim? Your goal?

Don't worry about your English, I'm sure it's good enough to understand. :-)

Cheers,

scoonma

Hm. Wouldn't it be easier and more clean to "rpm -q gcc" and "urpmi gcc" if the first fails? Anything else I'd give as parmeters to .configure (see ./configure --help | less). Plus checking the makefile before "make".

Which means do you use installing the KDE theme?

i would prefer to just be able to have the system install stuff that i want....but i do want to learn how to compile my own...thats why ive gone linux after all....am fed up with being spoon fed dross and told to like it.

:-) This is one of the main reasons why I do like modern linux that much: You *can* compile software on your own, but you're definitely not bound to, and the supply of well done .rpm packages is growing broader every day. It is handy especially in the beginning. Rpmdrake, diskdrake, urpmi and MCC as a whole made my decision for Mandriva. No other distro offers this level of comfort.

Problems popping up with MCC are often caused by strange, new (i.e. non-standard) hardware layouts and companies not willing to give access to interface info. Winmodems? GDI printers? Who the '*$scrx*% designs "standard" hardware but laid-out for a singular OS?!? Argh! Someone should arrest these guys and condemn them to work on MACs ;-)

Cheers,

scoonma

Hi Patkos,

when you're able to choose freely, I'd recommend the CD/DVD method and upgrade the system all in once. One reason is, you get your kernel updated just as well and at the same time as all packages.

I've done step by step upgrades regularly with at least every major version since Mandrake 8.0 was out and never ran into fatal errors using CDs. Just be careful with partitioning: Choose the manual variant and don't let the routine touch your /home partition. You can simply remount and reuse it, but take note of partition names before updating (check "less /etc/fstab" or use diskdrake).

Personal configuration for applications which store your options in $HOME cause fewest problems. You may have to do some adjustustment for standard repository software. Most issues are likely to emerge in /etc with this one. But it depends on how far is your system away from an out of the box version here. New config files/variants are inserted with .rpmnew suffix by default leaving your old settings intact. But some of them will have changed, be obsolete etc. in the new version. At least keep an eye on software which took major steps (shorewall for instance).

If you have a lot of software installed deriving from other sources, well, it depends on how robust is their source layout: Are they capable to find and use newer system libraries than the ones shipped with 2006? It's impossible to make a guess here: You may be lucky and they all run like before, but probably you have to recompile at least some of them. There's also changes of the software available: Stuff you've installed before using tarballs may be available in the contrib branch (or even in main?) now. So you maybe like to check which packages 2007 offers in detail before.

Good luck,

scoonma

Hi rob,

you wrote:

edit....ps....do make, make install, make clean work with mandriva?

As an experienced UNIX user, you'd probably like to use vi for editing. There's also nano, joe and emacs. Standard shell is bash, tcsh is also supported well.

Ps is here too, but options are likely a bit different to what you're used to. (see manpage)

Most tarballs come with a "/.configure" script, so if you want to do manual installations, standard procedure is

make

make install

Make is GNU make, cc is gcc and manual installations go into /usr/local/bin by default. There's autoconf and automake, too. But it's much easier to use preconfigured .rpm packages with ready-to-use binaries, scripts and Mandriva system tuned options. You're supposed to run into problems when mixing stuff from .rpms and manually compiled code, especially when it comes to libraries. So you'll normally get along well with standard packages. Before doing manual installs, you should check software repositories suggested to integrate by easy-urpmi (URL is in the top frame of this pages.)

To overview the software you've already installed from your live cd, use the software module from Mandrake Control Center (su; then mcc from terminal) or check packages with "urpmq --list | less". Access to package info is simple done by "urpmq -i <package-name>". It's a new world to discover on it's own. But all in all chances are good you'll get familiar with Mandriva fast. :D

Have fun!

scoonma

i hope that i'm doing this right but here is the error "The file file:///home/dennis/tmp/kde-dennis/jre-1_5_0_06-linux-i586-rpm(2).bin is a binary, saving it will result in a corrupt file." the distribution version is mandriva linux one

Which application are you using to downlad this file? Is it Konqueror? Firefox doesn't behave that way. The filename also suggests you have at least two copies of the package. I'd delete all instances of the file, then reload the file (once is enough!). Then open a terminal window (shell) and type the following commands in order:

cd /home/dennis/tmp/kde-dennis
su (followed by your root password)
chmod u+x jre-1_5_0_06-linux-i586-rpm.bin
./jre-1_5_0_06-linux-i586-rpm.bin

(See also http://www.java.com/en/download/help/50000...#selfextracting )

The first command is used to enter the directory where you downloaded the installation package. With the second one you change to root acces (which is necessary if for system wide installation). The third one applies executable permission to the file, and the last one acutally executes it. If you're done with that, type "logout" or "exit" (*Always* remember to logout after working as root!)

Normal software installation is much easier, so you can use the the graphical frontend Mandrake Control Center (MCC) in those cases, but java does not fully belong to the world of of free software. Thus license inkongruities are causing some installation trouble. :-(

Within Konqueror you have to activate Java support from the preferences. I'm not sure wether is sufficient. Firefox needs an additional symbolic link from the plugin directory of it's installation tree, as stated in this document by Sun:

http://www.java.com/en/download/help/5000010500.xml#enable

If you want to use flashplayer, you have the choice between the proprietary version from Adobe (with the need for some manual installation commands, too), or use the free swf player gnash. You can easily install gnash using MCC. Just try the software module here.

HTH,

scoonma

PS.: You don't have to post your request twice. B)

Hi Denn,

The instructions from java.com worked for me with several Mandriva and browser versions, flashplayer and java running smoothly. (Please tell us which software from Adobe you want to use as well; Adobe is just the name of the company.)

It's easier to help if you gave us some more details:

- Which distribution version are you using (and which version)?

- What is exact error message, and what is the name of the file being reported as corrupt?

Welcome to the wonderful world of free software!

scoonma

Sorry to here XGL doesn't work for you.

Don't worry, I'm considering 3D desktop as a feature just to play with by now. ;-)

3D and XGLboth work for me. Just lost Aiglx when I installed the propritary drivers.

This is what amazes with your config! The combination "ati drivers from xorg" plus Xgl was never possible here, with the Xgl option also greyed out by the new 3D desktop configuration module in MCC whenever using ati/xorg. OTOH, if I chose to use the proprietary drivers, the option itself is working, but functionality is not there (yet?).

Your xorg.conf reflects settings for both the proprietary and the free solution, with the latter one activated. But there's no loading of the Composite Extension?!? I always thought that would be an absolute necessity with the xorg drivers to get 3D desktop functions working with Xgl.

Folks here state the Composite Extension would only be necessary with nvidia, and it should not be used for ATI:

http://www.debianforum.de/forum/viewtopic....1aa5bb0c7d3bf50

But this cannot be the whole truth, otherwise those message stating the extension being missed would not show up here in .xsession-errors. I'm wondering wether the mainboard is troublemaker: It has an nforce2 chip layout, so the module nvidia-agp is used, no matter what's being loaded later on. Setting "UseInternalAGPGART" to "on" or "off" makes no difference.

Still being puzzled...

scoonma

No problem about the move. :-)

I've checked Xgl now and... nope! .xsession-errors clearly states that Composite Extension is needed by Xgl, but enabling that within xorg.conf disables 3D acceleration for the fglrx driver at all. So if you have a more recent ATI card (r300 and up) and want to try out the new 3D desktop features, you seem to be bound to the xorg/AIGLX combination at the moment (but I don't know wether you can overcome this by compiling Xgl 'n stuff yourself - not that I'd advise it if you're not really sure how to do that).

Cheers,

scoonma

GNOME 2.16 is out.

What is even better, integration into Cooker has already started; totem for instance is version 2.16.0 yet (with the *most incredible* goom you've ever seen)!

You shouldn't partition /root separately. This should be "/" and not /root.

Yeah, should've been / instead of /root. (Obviously caused by constantly calling it the "root partition".) Sorry, my mistake!

Doesn't deleting a file from an ext3 partition mean it's gone forever? AFAIK, you can recover files from an ext2 partition, but not from ext3.

Well... no. Try "urpmq -i magicrescue". That nice thingy works on any filesystem. :-)

If shorewall is causing that big amount of log data, you can simply edit /etc/shorewall.conf to suit your needs. It's possible to choose between multiple log levels for different "hit" conditions.

Cheers,

scoonma

This is really valuable. Probably we should try to collect well working combinations of video cards and corresponding configuration files. Xorg.conf settings can be nasty sometimes, and information about all those options, their meanings and working combinations seems to be spread all over the net.

I've managed to get the fglrx driver for my ATI 9600SE working again. Xgl is untried yet, but I'll do this soon. However, there's another point which gave some trouble: The proprietary driver (plus the plf one, which basically seem to deliver a stripped version of those files) obviously does not like to coexist with some regular libGL files. Main goal was a coexistence of both solutions. My xorg.conf has two Device sections, one for ati/radeon from xorg and one for the fglrx driver. By simply changing the device name (the name identifier) within the screen section below I hoped to be able to switch drivers (plus restarting X of course). But that would've been too easy, right?

Fglrx installs his libGL.so.1.2 in /usr/lib/ati (plus symbolic link), the regular libGL.so.1.2 resides in /usr/lib though. Only after renaming the regular one and setting a link at the other library the driver wanted to do 3D hardware rendering. What puzzles me is the fact that it's actually running now (fglrxinfo and fgl_glxgears do work), but the sceen startx is being executed from displays the following:

(EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/dri/fglrxdri.so: undefined symbol CreateNewScreen_20050727)

(EE) AIGLX: reverting so software rendering

For me this looks like an unsuccessful library call, and in every other similar case before 3D rendering was not possible (if X would start working at all; normally X refuses to start on *every* strict error as I've experienced). Or do the messages just mean the very special AIGLX part (from xorg) won't work, but the libraries from fglrx origin can compensate, and using Xgl might be possible regardless?

However, many thanks again for the config file!

scoonma