[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linrad] Re: Linux distributions



KD7HGL wrote:


richard wrote:

leif@xxxxxxxxxx wrote:


The down side to linrad is manually entering into /dev with mknod every time the machine is powered up.


I have used svgalib in the root only mode W/O the helper just fine. Yes, you need to run linrad as root, but that has never caused me any problems.


???
I did not try Mandriva, but nobody told me that the "make svgalib" does
not work.


Well I sorta did
Hi Guys,
Installing on Mandriva 2006 kernel-2.6.12-15mdk, all the svgalibs are available as rpms, I had to fool ./configure by creating a directory /usr/src/svgalib/ and adding a version file.
svgalib_helper is a module so no problems.
just one so far no /dev/svga exists.
Does anyone know the major and minor numbers to use mknod to create /dev/svga


mknod -m 666 /dev/svga c 209 0
mknod -m 666 /dev/svga1 c 209 1
mknod -m 666 /dev/svga2 c 209 2
mknod -m 666 /dev/svga3 c 209 3
mknod -m 666 /dev/svga4 c 209 4



If you use tar balls to blat over a stable system that uses RPM ,and has all the svgalib packages
available as RPMs its asking for trouble.
I spend a lot of my time sorting out systems were someone has blatted a tar ball over the top of a RPM data base, which then loses all its info on updates, the dependency tables are then corrupted. Mandriva make use extensively of URPMI, if you urpmi <package> it will not only go and get the package but install all its dependencies. I've tried many times to get linrad to run, and the only conclusion I come to each time is ,one computer for linrad and another for everything else.


Why do you think the Mandriva svga install will not work?
Because , when you try it it fails, you have to add little scripts to get it to function.

Tarballs vs RPMs. At work I run a bunch of Redhat systems and I frequently need to uninstall an RPM and install something from source. This works just fine. The main thing to remember is to remove the RPM before installing the tarball. There is nothing wrong with keeping a system with both types of packages.

Oh I strongly, strongly, utterly, indisputedly disagree, if you remove a RPM you break the dependencies on other packages that use the same RPM

Also most self installed programs will pick /usr/local as their install path so it is easy to see that this is a package that you installed.

Yup a Suse trick

One thing you can do is run:
make -n install
before you run make install. This will show you the steps make will use to install the package. If you don't like the paths it will install to, you can see this and make changes before you install the package.

You have done such good work with linrad Leif, its such a shame to the platforms it can run on diminish.


Distros are always changing. Given time I'm sure they will all work again soon.

As a temp fix mknod statements can be added to rc.local, but really it needs attention paid to the way the hotplug daemons behave.


Leif cannot maintain svgalib, I'm sure it will get better with time. Leif even provided a work around in his package. I think that is probably best case.

73, JOSH


I would never ask Leif to maintain the svgalibs, just to bear in mind that the package is old
and long in the tooth, and packages meeting those requisites die very quickly.

You only need to look at linrad and compare it with winrad, running in wine, and you can see
a big difference.
One's up and running in minutes, the other comes with a bottle of hair dye.
But I've been saying the same thing now for over a year, if linrad is to progress I really believe
it needs to move into a X window.
73 Richard

#############################################################
This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>

LINRADDARNIL