Re: [Cooker] U66 solved

2000-06-19 Thread Sebastian Dransfeld

On Mon, 19 Jun 2000, bobby dowling wrote:

> I tried hdparm -d1 -X66 /dev/hdX and I got a significant reduction in 
> performance:
> 
> Maxtor:  28mb/sec to 15 mb/sec
> WD: 22mb/sec to 20 mb/sec
> 
> So, I guess I will just leave the dma setting off  (???).

With 28MB/s dma is definitly turned on. Probably by the kernel. I get
14MB/s on a U33 drive which isn't to old.

seb




[Cooker] new mutt RPM

2000-06-19 Thread Vincent Danen

FYI, for those mutt users out there, I've built RPMs for the new
version of mutt and posted them on my website and uploaded them to
mandrakesoft.

-- 
[EMAIL PROTECTED], OpenPGP key available on www.keyserver.net
Freezer Burn BBS:  telnet://bbs.freezer-burn.org . ICQ: 54924721
Webmaster for the Linux Portal Site Freezer Burn:  http://www.freezer-burn.org

Current Linux uptime: 11:45, days users, hrs and  mins.




Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Chris Armstrong

Accidentally replied to the wrong address. Here's the forward of the message I
posted in reply to Jose Sanchez.

-- 
Chris Armstrong
http://penguinmints.cx



On Mon, Jun 19, 2000 at 06:54:53PM -0400, Jose M. Sanchez wrote:
[clip...]
> |Runtime upgrades. No matter how ya look at it dpkg with apt is nothing but
> |heaven. apt-get install and apt-get dist upgrade. apt-get install
> |is convince but isn't this what mdk strives for ? dist upgrade is not only
> |convince but less hassle.
> 
> Less hassle = bigger problems.
> 
> There is a choice that was made with RPM, protect the user from doing
> anything stupid.
> 
> Deb does the opposite, assume the user knows what he/she is doing.
> 
> Sounds like you've been upgrading .debs a little too quickly...
> You've been lucky so far...

I've been using unstable Debian for over a year (Potato, and now Woody).
I've never run into a problem that I wasn't able to fix with more than 10
minutes of work, and they are few and far between.

[clip...]
> |in turn would
> |cost me about 4 to 5 hours of my time.
> |
> 
> huh? I guess you've not tried gnorpm... but I digress.
> 
> Gimp goes to 2.0 which requires a slew of updates. Those updates in turn
> "break" other applications on your system.
> 
> With DEB you can go ahead and install GIMP 2, breaking the other apps.

Wrong. Debian would NOT by default allow you to install Gimp 2. apt calculates
the dependancies so other packages WON'T break when you install one. Of
course, if you want to force the install anyway, you can.

> With RPM you are warned... yet you can still choose to overlook the warning
> as you obviously do. It seems that you have done this so much that your
> making the assumption that this is the correct way of doing things...
> 
> Well I have news for you... it's not!
> 
[clip...]
> |as well as a lot of P.O.ed users/developers/whatever/whatever. So that
> |virturally wipes out downloading the fresh new ISO or even buying a CD.
> |
> 
> Faulty logic.
> 
> You're implying that DEB is unaffected by upgrade downtime... not so.

It is affected far less. Sure, you can, every now and then, run into
problems when you're running the unstable or frozen version of Debian. But
even most of the times you _do_ run into problems, you can do an 
apt-get -f install or something just as simple.

> |What about option number 2 ? Sorry, but if had to sys admin a
> |network of over at
> |least 5,000 users I wouldn't want to spend 5 hours upgrading packages and
> |kicking RPM because of useless deps.
> |
> 
> Again failure to understand the process...
> 
> Deb is permitting you to install upgrades which it shouldn't.

Again, you're wrong. Same explanation I gave two paragraphs ago.

> RPM does not... no thanks I'll stick with RPM...
> 
> |Now let's look at this from a end-user perspective.
> |Different scenario, same feelings. mdk is aimed at the desktop user, hence
> |convince and friendlyness. Do the above and mentioned options of
> |upgrading
> |sound appealing ? Especially to someone likely coming from windows.
> |
> 
> Again faulty logic.
> The assumption is that Deb is immune for trouble during upgrades...
> Since it monitors them far less than RPM it is more trouble prone...

I don't understand where you're getting that information. apt is quite anal
about what it does or does not let you install by default.
--- end quoted text ---

Here's what I recommend:
Don't switch to Debian's package management. I was with Bryan with this
suggestion in the beginning, but I've changed my mind. What MDK needs to
do is _rewrite_ rpm (keeping compatibility with the file format),
making it easier and more convenient to use, and have better dependancy 
handling (You could also just build better front-ends, but I think we'd be better off 
with a more-well-thought-out rpm core).

I also recommend Mandrake go with the central-repository method of PM,
keeping a central repository of RPMs that have passed the guidelines of
Mandrake's packages. Then develop a tool similar to apt which fetches and
installs whatever RPMs. I know these things have been done to an extent with
RPM, but I think they need to be done better, and I believe Mandrake has the 
potential to execute it quite gracefully.

-- 
Chris Armstrong
http://penguinmints.cx




Re: [Cooker] U66 times?

2000-06-19 Thread Christopher Campbell



Are these fast times or what?




[root@vegan vegan]# hdparm -Tt /dev/hdf

/dev/hdf:
 Timing buffer-cache reads:   128 MB in  1.38 seconds = 92.75 MB/sec
 Timing buffered disk reads:  64 MB in 17.79 seconds =  3.60 MB/sec
[root@vegan vegan]# hdparm -Tt /dev/hde

/dev/hde:
 Timing buffer-cache reads:   128 MB in  1.39 seconds = 92.09 MB/sec
 Timing buffered disk reads:  64 MB in 18.61 seconds =  3.44 MB/sec




Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Patrick Poncet

"Guy T. Rice" wrote:

> Other than that, you've presented a number of arguments I can't argue with.
> I used to use Debian and I agree they have a far superior package system.
> But it just doesn't have the support.  I'd rather see RPM improved or some
> frontend written to support all the features of Debian's package system.
> THAT would be cool...

You said what I meant :)))





Re: [Cooker] U66 solved

2000-06-19 Thread Eugenio Diaz


--- bobby dowling <[EMAIL PROTECTED]> wrote:
> Both drives say that they are capable of the
> following:
> 
> DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3
> *udma4
> 
> I am supposing the star means that the drive is set
> to udma4, correct?

If you used "hdparm -I" then you get the info
unformatted directly from the drive, and yes the
asterisk indicates the mode the drive is currently set
to.
 
> These are my hdparm settings:
> 
> hdparm -q -c3 -q -A1 -q -m16
>
I guess you could use something like this:

hdparm -q -c3 -q -A1 -q -m16 -q -d1 -q -X68

=

Eugenio Diaz, BSEE/BSCE   
Linux Engineer
[EMAIL PROTECTED]

__
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/




Re: [Cooker] RPM(S) worst enemy but Mandrake's best friend...

2000-06-19 Thread Patrick Poncet

Hey!

I've been watching this thread and have not found it very constructive so far.  I 
beleive the subject seserves more
interest...

As an ex-debian user, and current happy mdk user (for both, SERVER and Desktop) I have 
to agree with a statement
made earlier in the thread:

Both package mgmt systems have their goods and bads, my experience confirms it.  For 
sure it looks like RPM has been
adopted as a standard.  So why not improve RPM rather than fighting about which one is 
better, which one screws up
the most, which one.#$%^#&!$!%^&@


I think what's lacking the most with RPM is a console based system (kinda like 
dselect)  that uses apt like
principles - i.e.: you select a package to install or upgrade from an rpm repository 
and all dependencies get
satisfied by downloading the required packages after confirmation from the user(Guys @ 
mdk, you already have the
algos ready from your 7.1 DrakX install script which by the way is really slick!).  
Although I agree totally that
mdk is aimed at the desktop and therefore GUI based apps, I truly beleive that it 
would be beneficial for mdk to
come up with such a tool.  Think about upgrading a remote system from a telnet or ssh 
session for example.

By the way, rpmdrake has never worked for me: it always hangs on generating 
dependencies list - gendepslist2 (I
posted a help msg here about it but never got an answer:((()

Anyways, I just thought I'd put my $0.02 in, just to mention some lacks I see and 
experience in RPM...  Some of you
may think it's pointless, but I spoke anyways :)

Cheers everyone!

Peace,

Patrick.






Re: [Cooker] U66 solved

2000-06-19 Thread Eugenio Diaz

--- bobby dowling <[EMAIL PROTECTED]> wrote:
> I tried hdparm -d1 -X66 /dev/hdX and I got a
> significant reduction in 
> performance:
> 
> Maxtor:  28mb/sec to 15 mb/sec
> WD: 22mb/sec to 20 mb/sec
> 
> So, I guess I will just leave the dma setting off 
> (???).

What that means is that probably your drive was
already using UDMA4 (-X68), and you turned it down to
UDMA2 (-X66).

=

Eugenio Diaz, BSEE/BSCE   
Linux Engineer
[EMAIL PROTECTED]

__
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/




Re: [Cooker] Wheel mouse support in 7.1/Cooker

2000-06-19 Thread Guy T. Rice

On Mon, 19 Jun 2000, Roberto Rosselli Del Turco wrote:
> details like this; even Netscape is behaving funny, when I launch it the
> window is blank and useless for about 5 minutes, then it comes to life:
> never seen this before, abrupt termination was the norm :)

I have seen that before, when my DNS server is down.  Check resolv.conf,
and try pinging the nameservers specified there to see if they're up.




Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Guy T. Rice

On Mon, 19 Jun 2000, Bryan Paxton wrote:
> Debian's package system is right there to be used, why try to re-invent the
> wheel ? It just doesn't make sense to do so.
> 
> But what are the drawbacks ? Are there any at all ?

Well, simply put, if the day comes that I can't go to a vendor's website,
download their RPM for RedHat, and have it work flawlessly under Mandrake,
that will be the day I stop using Mandrake.

Other than that, you've presented a number of arguments I can't argue with.
I used to use Debian and I agree they have a far superior package system.
But it just doesn't have the support.  I'd rather see RPM improved or some
frontend written to support all the features of Debian's package system.
THAT would be cool...




[Cooker] broken mirrors

2000-06-19 Thread David Foresman

I mirror cooker pretty much every day.  for the last several days whenever a
new package has been announced on the announce list, the old package is
deleted off the mirror but the new pakage is never downloaded.

I use rpmfind.net and sunsite.uio.no for mirrors.




[Cooker] xchat dcc send fail

2000-06-19 Thread ckmb


The dcc send feature in xchat no longer works in 7.1.
Uninstalling it and installing the version from 7.0 it works again.




Re: [Cooker] Install from running environment?

2000-06-19 Thread ckmb


>
> > > > Is there a a way to install 7.1 from within a running version 
of
> > > > linux if it is already running the same kernel? I don't see 
any
> > > > problem with this but I don't know how to do it.
> > >
> > > you mean upgrade ???
> > >
> > Yes and no.
> >
> > There are some machines which I can get the hardware working but
> > refuse to do so as part of the standard install. I'd like to set 
up
> > the loaded modules and networking etc.. and then do an install or 
an
> > upgrade. I don't care if it has to remount the filesystems in read
> > only.
>
> doesn't this (from mandrake.com/en/heliumlast.php3) help?
>
> 
> Kernel oops'es
> what: the kernel crashes
> when: with some unusual hardware (eg: megaraid)
> solution: use your own custom kernel together with blank.img.
> The custom kernel must contain every driver needed for the 
installation.
> You
> can't provide modules. It must also be less than 700KB to fit on the
> floppy.
> Just create a boot floppy out of blank.img (the way you would do 
with
> images/cdrom.img), then mcopy vmlinuz a: where vmlinuz is your 
custom
> kernel.
> 
>
> if not, what would you use for the pre-install?

I'll give it a go. The problem I encounter is acutally that the plip 
module is no longer included in the network.img so I can't install it 
onto a laptop I've got. It was included in mdk7. It seems that the 
plip module has to be from the same kernel to communicate with my 
machine correctly (2.2.15-4) so I can't use the network image from 
mdk7. And I'm afraid I dont know how to change the image to include 
it. I also don't know how to open a shell and load it manually from 
elsewhere.




Re: [Cooker] RPM(S) worst enemy but Mandrake's best friend...

2000-06-19 Thread Bryan Paxton

On Mon, 19 Jun 2000, Frank Meurer wrote:
> On Mon, 19 Jun 2000, Bryan Paxton wrote:
> 
> > 1). deb yes just a tar.bz2 with shell scripts for install and uninstall. But
> > what's wrong with this ? Look at FreeBSD ports.
> I look at it.
> I'm using OpenBSD and someday I will use rpm also on OpenBSD, promised!
> 
> > 2). opts ? optimization aren't handled by RPM, they're handled by gcc(e.g.: 
>-march=i586)
> > Rebuilding a SRPM with --target= is almost useless in the situations I've 
>encountered, ala it never works : )
> 
> As I sayed: A rpm is always as good as its creator! ;-)
> I've done some srpms which I can compile with different targets. The srpms
> only build in my private environment but I can specify "target=i[345]86"
> to compile on my developer box and I can also specify "target=m68k" which
> does crosscompiling for Linux/m68k.
> Yes, it works *always*. ;-)
> 

heh *nod*
 
> [...]
> > > > rpm -Uvh gnome-libs-1.2.1-2mdk.alpha.rpm> > error: failed dependencies:
> > > > libart_lgpl.so.2 is needed by ee-0.3.11-5mdk
> > > > libart_lgpl.so.2 is needed by libglade-0.13-1mdk
> > > > libart_lgpl.so.2 is needed by gnome-media-1.0.51-3mdk
> > > > libart_lgpl.so.2 is needed by gnome-linuxconf-0.23-2mdk
> > > > libart_lgpl.so.2 is needed by gtop-1.0.7-0.4mdk
> > > > libart_lgpl.so.2 is needed by gnomba-0.6.2-4mdk
> Hey! You forgot "--nodeps"! ;-)
> 
> > What kind of dep handling is that ? As far as informative goes. 
> > I'm sure there is a simple hack to get rpm to list the package instead of the 
> > file name needed. This is one of the problems that make people(even users of rpm
> > based distros) cringe. 
> But if you take care of it on creating the spec file by specifying "Requires"
> and make a tough configuration of your rpm app (e.g. no auto-requires) then
> you can build fine rpms - that kind of rpms I mentioned before.
> That's IMHO *not* a rpm pb.
> And it's still more powerful than deb-packages.
> 

Once again *nod*

> > Also, how do we stop all the --forces ? I know from my brief experience with 
> > debian I _never_ had to force a package to install. The question is, is this
> > a result of bad maintaining of the .spec files ? Or is this simply RPM's ugly 
> > side ? Remember, too many --forces can corrupt a DB and turn-off a user from 
> > even wanting to mess with said package.
> Er... in this case above "--force" won't work IMHO!
> 

hrmmm ? what won't work ?

> > Runtime upgrades. No matter how ya look at it dpkg with apt is nothing but 
> > heaven. apt-get install and apt-get dist upgrade. apt-get install is convience
> > but isn't this what mdk strives for ? dist upgrade is not only convience but 
> > less hassle. Lets say the next ver of mdk comes out, i have two choices on how
> > to upgrade to 7.x. I can:
> As I understand apt-get is a single application. You are comparing two
> applications to one rpm application? I don't know much of the GUI and other
> high-level stuff, but AFAIK there are of course applications for automatic
> resolving of dependancies.
> 
> > 1) Download a 650 meg ISO, burn it, pop it in, reboot and have a downtime of 
> > about roughly an hour or so. 
> > 
> > 2). I can manually go get every package I need, then to find out that I need 
> > more packages to go along with the said packages to upgrade, which in turn would
> > cost me about 4 to 5 hours of my time. 
> What about mandrake-update?
> 
> > Doesn't this just seem ridculous ? It does to me. The only time i feel I should 
> > have to reboot of my own will is a kernel upgrade. 
> > 
> > Let's also look at this from a sys admin perspective if mdk ever wants to gain
> > market in that dept. 1 minute of downtime could cost a company X amount of money
> > as well as a lot of P.O.ed users/developers/managment/whatever. So that
> > virturally wipes out downloading the fresh new ISO or even buying a CD. 
> If downtime will cost a company much money then you can be sure that this
> company will have RAID-arrays, separate production and test server and more...
> 
> > What about option number 2 ? Sorry, but if had to sys admin a network of over at
> > least 5,000 users I wouldn't want to spend 5 hours upgrading packages and 
> > kicking RPM because of useless deps. 
> Then you should think over your strategy.
> You are not speaking of a rpm pb, you are speaking of general thoughts for
> administration of big systems.

*nod* but why not jump in ahead to offer something appealing and easy to manage
for the sys admin ?


> > Now let's look at this from a end-user perspective.
> > Different scenario, same feelings. mdk is aimed at the desktop user, hence
> > convience and friendlyness. Do the above and mentioned options of upgrading 
> > sound appealing ? Especially to someone likely coming from windows. 
> The desktop user has his/her nice, clickable, multi-colored GUI apps.
> 

Most of these apps completely suck IMHO. 
The functionality is horrible as in what it can and 

Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Bryan Paxton

On Mon, 19 Jun 2000, Jose M. Sanchez wrote:
> |-Original Message-
> |From: Bryan Paxton [mailto:[EMAIL PROTECTED]]
> |Sent: Monday, June 19, 2000 5:43 PM
> |To: [EMAIL PROTECTED]
> |Subject: Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...
> |
> |
> |I'm gonna go ahead and knock out all the replies out in one replied
> |of my own.
> |
> |1). deb yes just a tar.bz2 with shell scripts for install and
> |uninstall. But
> |what's wrong with this ? Look at FreeBSD ports.
> |
> 
> RPM does far more than DEB in this respect... pick up Maximum RPM for
> starters...
> 
I'll grant you this.

> |2). opts ? optimization aren't handled by RPM, they're handled by
> |gcc(e.g.: -march=i586)
> |Rebuilding a SRPM with --target= is almost useless in the
> |situations I've encountered, ala it never works : )
> |
> 
> Probably due to your insistence on mixing distros...
> 
heh no, snag say glibc*.srpm && rpm --rebuild --target=whatever
watch the gcc flags

> |3). LSB does advocate RPM as the standard for package management,
> |RPM has a long
> |way to go before it ever becomes the standard in a server
> |environment though.
> |Though mdk is not aimed at the server dept. either, so who knows
> |on that one.
> |
> 
> Well, let's see. Mandrake & Redhat provide "server" services. As a result
> RPM has a preponderance of users. How do you define a standard?
> 
> Thanks I'll stick with RPM until something better comes along...

RPM server is nothing but a security hole and a slew of exploits waiting to
happen, why do you think noone uses it ? 
 
>
> |Now, let's look at some of the things that could be improve RPM.
> |
> |Starting simple, in a previous post I read on here.
> |
> |> > rpm -Uvh gnome-libs-1.2.1-2mdk.alpha.rpm> > error: failed dependencies:
> |> > libart_lgpl.so.2 is needed by ee-0.3.11-5mdk
> |> > libart_lgpl.so.2 is needed by libglade-0.13-1mdk
> |> > libart_lgpl.so.2 is needed by gnome-media-1.0.51-3mdk
> |> > libart_lgpl.so.2 is needed by gnome-linuxconf-0.23-2mdk
> |> > libart_lgpl.so.2 is needed by gtop-1.0.7-0.4mdk
> |> > libart_lgpl.so.2 is needed by gnomba-0.6.2-4mdk
> |
> |What kind of dep handling is that ? As far as informative goes.
> |I'm sure there is a simple hack to get rpm to list the package
> |instead of the
> |file name needed. This is one of the problems that make
> |people(even users of rpm
> |based distros) cringe.
> |
> 
> What's wrong with this?
> 
> RPM is warning you that you are about to affect the other packages listed...
> 
You by far missed the point on this one. 
The warning message does not display what package lib* is part of and what
you are breaking. Though this is due to poor spec maintaining I assume.

Remember, too many --forces can corrupt a DB and turn-off a
> |user from
> |even wanting to mess with said package.
> |
> 
> --forces are normally the result of the user choosing to "step beyond" the
> distribution. Since the new package which is being installed may require
> some other lib etc. people often --force the installation.
> 
--forces are every day life for 99.9% of all users using an RPM based distro.
Go to an irc newbies channel and count how many people come in with these 
problems. This again can also be traced back to poor maintaining of spec files.


> |Runtime upgrades. No matter how ya look at it dpkg with apt is nothing but
> |heaven. apt-get install and apt-get dist upgrade. apt-get install
> |is convince but isn't this what mdk strives for ? dist upgrade is not only
> |convince but less hassle.
> 
> Less hassle = bigger problems.
if [[ $less_hassle == $bigger_problems ]]; then
echo "Lay out all possible problems that one would encounter with a dist upgrade
and elminate the source of the problem"
else
echo "Let's stay in the stone age"
fi

> |Lets say the next ver of mdk comes out, i have two
> |choices on how
> |to upgrade to 7.x. I can:
> |
> |1) Download a 650 meg ISO, burn it, pop it in, reboot and have a
> |downtime of
> |about roughly an hour or so.
> |
> |2). I can manually go get every package I need, then to find out
> |that I need
> |more packages to go along with the said packages to upgrade, which
> |in turn would
> |cost me about 4 to 5 hours of my time.
> |
> 
> huh? I guess you've not tried gnorpm... but I digress.
You're gonna compare gnorpm to apt ?
That's apples and oranges man.

> 
> Gimp goes to 2.0 which requires a slew of updates. Those updates in turn
> "break" other applications on your system.
> 
> With DEB you can go ahead and install GIMP 2, breaking the other apps.
It sounds like you haven't played with dist upgrades a lot.
WARNING messages are given if one package will break another.

> 
> |Doesn't this just seem ridculous ? It does to me. The only time i
> |feel I should
> |have to reboot of my own will is a kernel upgrade.
> |
> |Let's also look at this from a sys admin perspective if mdk ever
> |wants to gain
> |market in that dept. 1 minute of downtime c

RE: [Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Jose M. Sanchez



|-Original Message-
|From: Bryan Paxton [mailto:[EMAIL PROTECTED]]
|Sent: Monday, June 19, 2000 5:43 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...
|
|
|I'm gonna go ahead and knock out all the replies out in one replied
|of my own.
|
|1). deb yes just a tar.bz2 with shell scripts for install and
|uninstall. But
|what's wrong with this ? Look at FreeBSD ports.
|

RPM does far more than DEB in this respect... pick up Maximum RPM for
starters...

|2). opts ? optimization aren't handled by RPM, they're handled by
|gcc(e.g.: -march=i586)
|Rebuilding a SRPM with --target= is almost useless in the
|situations I've encountered, ala it never works : )
|

Probably due to your insistence on mixing distros...

RPM is pretty good at keeping things straight, vis-à-vis dependencies, etc.

If you follow the guidelines your RPM's will normally rebuild without a
hitch, provided of course you've met their requirements...

I've rarely had one fail...

|3). LSB does advocate RPM as the standard for package management,
|RPM has a long
|way to go before it ever becomes the standard in a server
|environment though.
|Though mdk is not aimed at the server dept. either, so who knows
|on that one.
|

Well, let's see. Mandrake & Redhat provide "server" services. As a result
RPM has a preponderance of users. How do you define a standard?

Thanks I'll stick with RPM until something better comes along...



|Now, let's look at some of the things that could be improve RPM.
|
|Starting simple, in a previous post I read on here.
|
|> > rpm -Uvh gnome-libs-1.2.1-2mdk.alpha.rpm> > error: failed dependencies:
|> > libart_lgpl.so.2 is needed by ee-0.3.11-5mdk
|> > libart_lgpl.so.2 is needed by libglade-0.13-1mdk
|> > libart_lgpl.so.2 is needed by gnome-media-1.0.51-3mdk
|> > libart_lgpl.so.2 is needed by gnome-linuxconf-0.23-2mdk
|> > libart_lgpl.so.2 is needed by gtop-1.0.7-0.4mdk
|> > libart_lgpl.so.2 is needed by gnomba-0.6.2-4mdk
|
|What kind of dep handling is that ? As far as informative goes.
|I'm sure there is a simple hack to get rpm to list the package
|instead of the
|file name needed. This is one of the problems that make
|people(even users of rpm
|based distros) cringe.
|

What's wrong with this?

RPM is warning you that you are about to affect the other packages listed...

Had you dumped the corresponding updated RPM's into the same directory and
attempted to install them all at the same time, RPM would have handled this
for you all automatically...

|Also, how do we stop all the --forces ? I know from my brief
|experience with
|debian I _never_ had to force a package to install. The question
|is, is this
|a result of bad maintaining of the .spec files ? Or is this simply
|RPM's ugly
|side ? Remember, too many --forces can corrupt a DB and turn-off a
|user from
|even wanting to mess with said package.
|

--forces are normally the result of the user choosing to "step beyond" the
distribution. Since the new package which is being installed may require
some other lib etc. people often --force the installation.

This is akin to what the Winblows installers do... they merrily replace the
DLL's with whatever the current package needs, blithely overwriting
important system resources...

Deb is pretty weak in this respect, you can proceed without being "forced"
to do this...

Stick with packages built specifically for the distro, and you almost never
have to use --force. Or grab the src.rpm and build them yourself often
"adjusting" the resulting RPM to your own system.


|Runtime upgrades. No matter how ya look at it dpkg with apt is nothing but
|heaven. apt-get install and apt-get dist upgrade. apt-get install
|is convince but isn't this what mdk strives for ? dist upgrade is not only
|convince but less hassle.

Less hassle = bigger problems.

There is a choice that was made with RPM, protect the user from doing
anything stupid.

Deb does the opposite, assume the user knows what he/she is doing.

Sounds like you've been upgrading .debs a little too quickly...
You've been lucky so far...


|Lets say the next ver of mdk comes out, i have two
|choices on how
|to upgrade to 7.x. I can:
|
|1) Download a 650 meg ISO, burn it, pop it in, reboot and have a
|downtime of
|about roughly an hour or so.
|
|2). I can manually go get every package I need, then to find out
|that I need
|more packages to go along with the said packages to upgrade, which
|in turn would
|cost me about 4 to 5 hours of my time.
|

huh? I guess you've not tried gnorpm... but I digress.

Gimp goes to 2.0 which requires a slew of updates. Those updates in turn
"break" other applications on your system.

With DEB you can go ahead and install GIMP 2, breaking the other apps.

With RPM you are warned... yet you can still choose to overlook the warning
as you obviously do. It seems that you have done this so much that your
making the assumption that this is the correct way

Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Frank Meurer

On Mon, 19 Jun 2000, Bryan Paxton wrote:

> 1). deb yes just a tar.bz2 with shell scripts for install and uninstall. But
> what's wrong with this ? Look at FreeBSD ports.
I look at it.
I'm using OpenBSD and someday I will use rpm also on OpenBSD, promised!

> 2). opts ? optimization aren't handled by RPM, they're handled by gcc(e.g.: 
>-march=i586)
> Rebuilding a SRPM with --target= is almost useless in the situations I've 
>encountered, ala it never works : )

As I sayed: A rpm is always as good as its creator! ;-)
I've done some srpms which I can compile with different targets. The srpms
only build in my private environment but I can specify "target=i[345]86"
to compile on my developer box and I can also specify "target=m68k" which
does crosscompiling for Linux/m68k.
Yes, it works *always*. ;-)


[...]
> > > rpm -Uvh gnome-libs-1.2.1-2mdk.alpha.rpm> > error: failed dependencies:
> > > libart_lgpl.so.2 is needed by ee-0.3.11-5mdk
> > > libart_lgpl.so.2 is needed by libglade-0.13-1mdk
> > > libart_lgpl.so.2 is needed by gnome-media-1.0.51-3mdk
> > > libart_lgpl.so.2 is needed by gnome-linuxconf-0.23-2mdk
> > > libart_lgpl.so.2 is needed by gtop-1.0.7-0.4mdk
> > > libart_lgpl.so.2 is needed by gnomba-0.6.2-4mdk
Hey! You forgot "--nodeps"! ;-)

> What kind of dep handling is that ? As far as informative goes. 
> I'm sure there is a simple hack to get rpm to list the package instead of the 
> file name needed. This is one of the problems that make people(even users of rpm
> based distros) cringe. 
But if you take care of it on creating the spec file by specifying "Requires"
and make a tough configuration of your rpm app (e.g. no auto-requires) then
you can build fine rpms - that kind of rpms I mentioned before.
That's IMHO *not* a rpm pb.
And it's still more powerful than deb-packages.


> Also, how do we stop all the --forces ? I know from my brief experience with 
> debian I _never_ had to force a package to install. The question is, is this
> a result of bad maintaining of the .spec files ? Or is this simply RPM's ugly 
> side ? Remember, too many --forces can corrupt a DB and turn-off a user from 
> even wanting to mess with said package.
Er... in this case above "--force" won't work IMHO!

> Runtime upgrades. No matter how ya look at it dpkg with apt is nothing but 
> heaven. apt-get install and apt-get dist upgrade. apt-get install is convience
> but isn't this what mdk strives for ? dist upgrade is not only convience but 
> less hassle. Lets say the next ver of mdk comes out, i have two choices on how
> to upgrade to 7.x. I can:
As I understand apt-get is a single application. You are comparing two
applications to one rpm application? I don't know much of the GUI and other
high-level stuff, but AFAIK there are of course applications for automatic
resolving of dependancies.

> 1) Download a 650 meg ISO, burn it, pop it in, reboot and have a downtime of 
> about roughly an hour or so. 
> 
> 2). I can manually go get every package I need, then to find out that I need 
> more packages to go along with the said packages to upgrade, which in turn would
> cost me about 4 to 5 hours of my time. 
What about mandrake-update?

> Doesn't this just seem ridculous ? It does to me. The only time i feel I should 
> have to reboot of my own will is a kernel upgrade. 
> 
> Let's also look at this from a sys admin perspective if mdk ever wants to gain
> market in that dept. 1 minute of downtime could cost a company X amount of money
> as well as a lot of P.O.ed users/developers/managment/whatever. So that
> virturally wipes out downloading the fresh new ISO or even buying a CD. 
If downtime will cost a company much money then you can be sure that this
company will have RAID-arrays, separate production and test server and more...

> What about option number 2 ? Sorry, but if had to sys admin a network of over at
> least 5,000 users I wouldn't want to spend 5 hours upgrading packages and 
> kicking RPM because of useless deps. 
Then you should think over your strategy.
You are not speaking of a rpm pb, you are speaking of general thoughts for
administration of big systems.

> Now let's look at this from a end-user perspective.
> Different scenario, same feelings. mdk is aimed at the desktop user, hence
> convience and friendlyness. Do the above and mentioned options of upgrading 
> sound appealing ? Especially to someone likely coming from windows. 
The desktop user has his/her nice, clickable, multi-colored GUI apps.

> So what now.
Where's the problem?

Frank

-
Close the window, open the door, let in LINUX!

Sending unsolicited commercial email to this address may be a violation
of the Washington State Consumer Protection Act, chapter 19.86 RCW.
Das Verschicken unverlangter kommerzieller email an diese Adresse ist
verboten (LG Traunstein, 2 HK O 3755/97 vom 14.10.1997, CR 1998, 171f).

Re: [Cooker] memory detection

2000-06-19 Thread Danny Cook

Pixel
Thank you very much! I added the mem= option to my menu.lst file at it worked
great!

Thank you again!
Danny
> 
> excerpt from my /boot/grub/menu.lst:
> 
> title linux
> kernel (hd0,0)/boot/vmlinuz root=/dev/hda1 mem=128M
> 
> cu Pixel.




Re: [Cooker] U66 solved

2000-06-19 Thread Christopher Campbell



Ok Ok but how do you test the speeds of your drives?
My drive supports 
 Model=Maxtor 92720U8, FwRev=MA540RR0, SerialNo=C803RN7C
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=53177040
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 


so.. UDMA 4 is the fastest... I dont know what I am running
at right now.. is this told in the above information?
I mainly want to know if there is a way to benchmark your
throughput... 
Thanks.
Chrisopher Campbell


On Mon, 19 Jun 2000, you wrote:
> Did you do it specifiying both flags at the same time?
> 
> What -Xxx value did you use?
> 
> First query your drive with "hdparm -i /dev/hda" to
> see what modes your drive support.
> 
> From the hdparm man page:
> 
> ...
> 
>-X Set the IDE transfer  mode  for  newer 
> (E)IDE/ATA2
>   drives.  This is typically used in
> combination with
>   -d1 when enabling DMA to/from a  drive 
> on  a  sup
>   ported  interface  chipset (such as the
> Intel 430FX
>   Triton), where -X34 is used to select
> multiword DMA
>   mode2 transfers.  With systems which
> support Ultra
>   DMA burst timings, -X66 is used to
> select  UltraDMA
>   mode2 transfers (you'll need to prepare
> the chipset
>   for UltraDMA beforehand).  Apart from
> that, use  of
>   this flag is seldom necessary since
> most/all modern
>   IDE drives default to their  fastest 
> PIO  transfer
>   mode  at  power-on.  Fiddling with this
> can be both
>   needless and risky.  On drives which
> support alter
>   nate  transfer  modes, -X can be used to
> switch the
>   mode of the drive  only.   Prior  to 
> changing  the
>   transfer mode, the IDE interface should
> be jumpered
>   or programmed (see -p flag) for the new 
> mode  set
>   ting  to  prevent  loss  and/or
> corruption of data.
>   Use this with extreme caution!  For the 
> PIO  (Pro
>   grammed Input/Output) transfer modes
> used by Linux,
>   this value is simply the desired  PIO 
> mode  number
>   plus  8.   Thus,  a  value of 09 sets
> PIO mode1, 10
>   enables PIO mode2, and 11 selects PIO
> mode3.   Set
>   ting  00  restores  the drive's
> "default" PIO mode,
>   and 01 disables  IORDY.   For  multiword
>  DMA,  the
>   value  used is the desired DMA mode
> number plus 32.
>   for UltraDMA, the value  is  the 
> desired  UltraDMA
>   mode number plus 64.
> 
> ...
> 
> It says that most modern drives default to the fastest
> mode; he, he, he, I had always have to use hdparm to
> get an average of only *twice* the default performance
> with all the drives I have ever had. ;-)
> 
> --- Pixel <[EMAIL PROTECTED]> wrote:
> > "bobby dowling" <[EMAIL PROTECTED]> writes:
> > 
> > > What do you mean the -d flag without the -X flags?
> > > 
> > > So, you can say -dX and those WD drives that froze
> > the system before would 
> > > work?
> > 
> > nope, froze anyway here :(
> > 
> 
> 
> =
> 
> Eugenio Diaz, BSEE/BSCE   
> Linux Engineer
> [EMAIL PROTECTED]
> 
> __
> Do You Yahoo!?
> Send instant messages with Yahoo! Messenger.
> http://im.yahoo.com/




Re: [Cooker] U66 solved

2000-06-19 Thread bobby dowling

I tried hdparm -d1 -X66 /dev/hdX and I got a significant reduction in 
performance:

Maxtor:  28mb/sec to 15 mb/sec
WD: 22mb/sec to 20 mb/sec

So, I guess I will just leave the dma setting off  (???).


>From: Eugenio Diaz <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: [Cooker] U66 solved
>Date: Sun, 18 Jun 2000 22:47:53 -0700 (PDT)
>MIME-Version: 1.0
>Received: from [216.71.84.35] by hotmail.com (3.2) with ESMTP id 
>MHotMailBB16FF6F0062D820F3C8D84754234A0B0; Sun Jun 18 22:49:35 2000
>Received: (from sympa@localhost)by mandrakesoft.mandrakesoft.com 
>(8.8.5/8.8.5) id AAA00834for [EMAIL PROTECTED]; Mon, 19 Jun 2000 
>00:48:51 -0500
>Received: from web121.yahoomail.com (web121.yahoomail.com
>[205.180.60.129]) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP  
>   id AAA00302 for <[EMAIL PROTECTED]>; Mon, 19 Jun 2000 00:47:13   
>  -0500
>Received: (qmail 14189 invoked by uid 60001); 19 Jun 2000 05:47:53 -
>Received: from [207.36.26.197] by web121.yahoomail.com; Sun,18 Jun 2000 
>22:47:53 PDT
>From [EMAIL PROTECTED] Sun Jun 18 22:51:13 2000
>Message-Id: <[EMAIL PROTECTED]>
>X-Loop: [EMAIL PROTECTED]
>X-Sequence: 1232
>Precedence: list
>
>
>--- bobby dowling <[EMAIL PROTECTED]> wrote:
> > What do you mean the -d flag without the -X flags?
> >
> > So, you can say -dX and those WD drives that froze
> > the system before would
> > work?
>
>Nooo! For UltraDMA2 on your fisrst ide drive, it would
>be something like this (for an explanation of the
>number after the -X, see the man page of hdparm):
>
>hdparm -d1 -X66 /dev/hda
>
>or for an older EIDE drive:
>
>hdparm -d1 -X34 /dev/hda
>
>**Please note this is dangerous stuff; if you punch in
>a mode that does not corresponds to what your
>drive/controller is capable, under some circumstances
>it could lead to a corrupted file systems.
>
>=
>
>Eugenio Diaz, BSEE/BSCE
>Linux Engineer
>[EMAIL PROTECTED]
>
>__
>Do You Yahoo!?
>Send instant messages with Yahoo! Messenger.
>http://im.yahoo.com/
>


Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com




Re: [Cooker] U66 solved

2000-06-19 Thread bobby dowling

Both drives say that they are capable of the following:

DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4

I am supposing the star means that the drive is set to udma4, correct?

These are my hdparm settings:

hdparm -q -c3 -q -A1 -q -m16

This is what is specified in /etc/rc.d/init.d/mandrake_everytime (of course 
I specified HDPARM=yes in /etc/sysconfig/system).

I didn't specify the dma option because it always locks up the WD drive..

BTW, both drives were bought within the last 3 months, so I assume they are 
fairly new and should work with dma in linux.




>From: Eugenio Diaz <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: [Cooker] U66 solved
>Date: Mon, 19 Jun 2000 13:46:07 -0700 (PDT)
>MIME-Version: 1.0
>Received: from [216.71.84.35] by hotmail.com (3.2) with ESMTP id 
>MHotMailBB17D2D40073D820F39ED847542364490; Mon Jun 19 13:51:33 2000
>Received: (from sympa@localhost)by mandrakesoft.mandrakesoft.com 
>(8.8.5/8.8.5) id PAA08219for [EMAIL PROTECTED]; Mon, 19 Jun 2000 
>15:54:12 -0500
>Received: from web125.yahoomail.com (web125.yahoomail.com
>[205.180.60.193]) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP  
>   id PAA05577 for <[EMAIL PROTECTED]>; Mon, 19 Jun 2000 15:46:11   
>  -0500
>Received: (qmail 29612 invoked by uid 60001); 19 Jun 2000 20:46:07 -
>Received: from [207.36.26.1] by web125.yahoomail.com; Mon, 19 Jun 2000
>13:46:07 PDT
>From [EMAIL PROTECTED] Mon Jun 19 13:51:45 2000
>Message-Id: <[EMAIL PROTECTED]>
>X-Loop: [EMAIL PROTECTED]
>X-Sequence: 1282
>Precedence: list
>
>Did you do it specifiying both flags at the same time?
>
>What -Xxx value did you use?
>
>First query your drive with "hdparm -i /dev/hda" to
>see what modes your drive support.
>
>From the hdparm man page:
>
>...
>
>-X Set the IDE transfer  mode  for  newer
>(E)IDE/ATA2
>   drives.  This is typically used in
>combination with
>   -d1 when enabling DMA to/from a  drive
>on  a  sup
>   ported  interface  chipset (such as the
>Intel 430FX
>   Triton), where -X34 is used to select
>multiword DMA
>   mode2 transfers.  With systems which
>support Ultra
>   DMA burst timings, -X66 is used to
>select  UltraDMA
>   mode2 transfers (you'll need to prepare
>the chipset
>   for UltraDMA beforehand).  Apart from
>that, use  of
>   this flag is seldom necessary since
>most/all modern
>   IDE drives default to their  fastest
>PIO  transfer
>   mode  at  power-on.  Fiddling with this
>can be both
>   needless and risky.  On drives which
>support alter
>   nate  transfer  modes, -X can be used to
>switch the
>   mode of the drive  only.   Prior  to
>changing  the
>   transfer mode, the IDE interface should
>be jumpered
>   or programmed (see -p flag) for the new
>mode  set
>   ting  to  prevent  loss  and/or
>corruption of data.
>   Use this with extreme caution!  For the
>PIO  (Pro
>   grammed Input/Output) transfer modes
>used by Linux,
>   this value is simply the desired  PIO
>mode  number
>   plus  8.   Thus,  a  value of 09 sets
>PIO mode1, 10
>   enables PIO mode2, and 11 selects PIO
>mode3.   Set
>   ting  00  restores  the drive's
>"default" PIO mode,
>   and 01 disables  IORDY.   For  multiword
>  DMA,  the
>   value  used is the desired DMA mode
>number plus 32.
>   for UltraDMA, the value  is  the
>desired  UltraDMA
>   mode number plus 64.
>
>...
>
>It says that most modern drives default to the fastest
>mode; he, he, he, I had always have to use hdparm to
>get an average of only *twice* the default performance
>with all the drives I have ever had. ;-)
>
>--- Pixel <[EMAIL PROTECTED]> wrote:
> > "bobby dowling" <[EMAIL PROTECTED]> writes:
> >
> > > What do you mean the -d flag without the -X flags?
> > >
> > > So, you can say -dX and those WD drives that froze
> > the system before would
> > > work?
> >
> > nope, froze anyway here :(
> >
>
>
>=
>
>Eugenio Diaz, BSEE/BSCE
>Linux Engineer
>[EMAIL PROTECTED]
>
>__
>Do You Yahoo!?
>Send instant messages with Yahoo! Messenger.
>http://im.yahoo.com/
>


Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com




Re: [Cooker] memory detection

2000-06-19 Thread Pixel

Danny Cook <[EMAIL PROTECTED]> writes:

> Hello all,
> I just installed 7.1 on a newer computer and it does not detect my correct
> memory (256mb) It is showing only 64 mb. Windoze correctly detected the correct
> amount. I am pretty sure I typed in the correct value at installation.
> 
> >From what I have read at http://www.mandrakeuser.org/troubles/tquick4.html 
> and http://www.linuxnewbie.org/nhf/intel/hardware/ramdetect.html it is a bios
> detection problem but can be corrected by editing the lilo configuration file. 
> 
> My question is how can it be fixed when using the grub loader. Any help with
> this would be appreciated.

excerpt from my /boot/grub/menu.lst:

title linux
kernel (hd0,0)/boot/vmlinuz root=/dev/hda1 mem=128M


cu Pixel.




Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Bryan Paxton

I'm gonna go ahead and knock out all the replies out in one replie of my own.

1). deb yes just a tar.bz2 with shell scripts for install and uninstall. But
what's wrong with this ? Look at FreeBSD ports.

2). opts ? optimization aren't handled by RPM, they're handled by gcc(e.g.: 
-march=i586)
Rebuilding a SRPM with --target= is almost useless in the situations I've encountered, 
ala it never works : )

3). LSB does advocate RPM as the standard for package managment, RPM has a long
way to go before it ever becomes the standard in a server enviorment though.
Though mdk is not aimed at the server dept. either, so who knows on that one.

Now, let's look at some of the things that could be improve RPM.

Starting simple, in a previous post I read on here.

> > rpm -Uvh gnome-libs-1.2.1-2mdk.alpha.rpm> > error: failed dependencies:
> > libart_lgpl.so.2 is needed by ee-0.3.11-5mdk
> > libart_lgpl.so.2 is needed by libglade-0.13-1mdk
> > libart_lgpl.so.2 is needed by gnome-media-1.0.51-3mdk
> > libart_lgpl.so.2 is needed by gnome-linuxconf-0.23-2mdk
> > libart_lgpl.so.2 is needed by gtop-1.0.7-0.4mdk
> > libart_lgpl.so.2 is needed by gnomba-0.6.2-4mdk

What kind of dep handling is that ? As far as informative goes. 
I'm sure there is a simple hack to get rpm to list the package instead of the 
file name needed. This is one of the problems that make people(even users of rpm
based distros) cringe. 

Also, how do we stop all the --forces ? I know from my brief experience with 
debian I _never_ had to force a package to install. The question is, is this
a result of bad maintaining of the .spec files ? Or is this simply RPM's ugly 
side ? Remember, too many --forces can corrupt a DB and turn-off a user from 
even wanting to mess with said package.

Runtime upgrades. No matter how ya look at it dpkg with apt is nothing but 
heaven. apt-get install and apt-get dist upgrade. apt-get install is convience
but isn't this what mdk strives for ? dist upgrade is not only convience but 
less hassle. Lets say the next ver of mdk comes out, i have two choices on how
to upgrade to 7.x. I can:

1) Download a 650 meg ISO, burn it, pop it in, reboot and have a downtime of 
about roughly an hour or so. 

2). I can manually go get every package I need, then to find out that I need 
more packages to go along with the said packages to upgrade, which in turn would
cost me about 4 to 5 hours of my time. 

Doesn't this just seem ridculous ? It does to me. The only time i feel I should 
have to reboot of my own will is a kernel upgrade. 

Let's also look at this from a sys admin perspective if mdk ever wants to gain
market in that dept. 1 minute of downtime could cost a company X amount of money
as well as a lot of P.O.ed users/developers/managment/whatever. So that
virturally wipes out downloading the fresh new ISO or even buying a CD. 

What about option number 2 ? Sorry, but if had to sys admin a network of over at
least 5,000 users I wouldn't want to spend 5 hours upgrading packages and 
kicking RPM because of useless deps. 

Now let's look at this from a end-user perspective.
Different scenario, same feelings. mdk is aimed at the desktop user, hence
convience and friendlyness. Do the above and mentioned options of upgrading 
sound appealing ? Especially to someone likely coming from windows. 

So what now.

-- 
Bryan Paxton

"How should I know if it works? That's what beta testers are for. I
  only coded it."
 -- Linus Torvalds.

Public key can be found at http://speedbros.org/Bryan_Paxton.asc




[Cooker] memory detection

2000-06-19 Thread Danny Cook

Hello all,
I just installed 7.1 on a newer computer and it does not detect my correct
memory (256mb) It is showing only 64 mb. Windoze correctly detected the correct
amount. I am pretty sure I typed in the correct value at installation.

>From what I have read at http://www.mandrakeuser.org/troubles/tquick4.html 
and http://www.linuxnewbie.org/nhf/intel/hardware/ramdetect.html it is a bios
detection problem but can be corrected by editing the lilo configuration file. 

My question is how can it be fixed when using the grub loader. Any help with
this would be appreciated.

Thanks,
Danny Cook




Re: [Cooker] Install from running environment?

2000-06-19 Thread Pixel

[EMAIL PROTECTED] writes:

> > > Is there a a way to install 7.1 from within a running version of
> > > linux if it is already running the same kernel? I don't see any
> > > problem with this but I don't know how to do it.
> >
> > you mean upgrade ???
> >
> Yes and no.
> 
> There are some machines which I can get the hardware working but
> refuse to do so as part of the standard install. I'd like to set up
> the loaded modules and networking etc.. and then do an install or an
> upgrade. I don't care if it has to remount the filesystems in read
> only.

doesn't this (from mandrake.com/en/heliumlast.php3) help?


Kernel oops'es
what: the kernel crashes
when: with some unusual hardware (eg: megaraid)
solution: use your own custom kernel together with blank.img.
The custom kernel must contain every driver needed for the installation. You
can't provide modules. It must also be less than 700KB to fit on the floppy.
Just create a boot floppy out of blank.img (the way you would do with
images/cdrom.img), then mcopy vmlinuz a: where vmlinuz is your custom kernel.


if not, what would you use for the pre-install?




Re: [Cooker] U66 solved

2000-06-19 Thread Eugenio Diaz

Did you do it specifiying both flags at the same time?

What -Xxx value did you use?

First query your drive with "hdparm -i /dev/hda" to
see what modes your drive support.

>From the hdparm man page:

...

   -X Set the IDE transfer  mode  for  newer 
(E)IDE/ATA2
  drives.  This is typically used in
combination with
  -d1 when enabling DMA to/from a  drive 
on  a  sup
  ported  interface  chipset (such as the
Intel 430FX
  Triton), where -X34 is used to select
multiword DMA
  mode2 transfers.  With systems which
support Ultra
  DMA burst timings, -X66 is used to
select  UltraDMA
  mode2 transfers (you'll need to prepare
the chipset
  for UltraDMA beforehand).  Apart from
that, use  of
  this flag is seldom necessary since
most/all modern
  IDE drives default to their  fastest 
PIO  transfer
  mode  at  power-on.  Fiddling with this
can be both
  needless and risky.  On drives which
support alter
  nate  transfer  modes, -X can be used to
switch the
  mode of the drive  only.   Prior  to 
changing  the
  transfer mode, the IDE interface should
be jumpered
  or programmed (see -p flag) for the new 
mode  set
  ting  to  prevent  loss  and/or
corruption of data.
  Use this with extreme caution!  For the 
PIO  (Pro
  grammed Input/Output) transfer modes
used by Linux,
  this value is simply the desired  PIO 
mode  number
  plus  8.   Thus,  a  value of 09 sets
PIO mode1, 10
  enables PIO mode2, and 11 selects PIO
mode3.   Set
  ting  00  restores  the drive's
"default" PIO mode,
  and 01 disables  IORDY.   For  multiword
 DMA,  the
  value  used is the desired DMA mode
number plus 32.
  for UltraDMA, the value  is  the 
desired  UltraDMA
  mode number plus 64.

...

It says that most modern drives default to the fastest
mode; he, he, he, I had always have to use hdparm to
get an average of only *twice* the default performance
with all the drives I have ever had. ;-)

--- Pixel <[EMAIL PROTECTED]> wrote:
> "bobby dowling" <[EMAIL PROTECTED]> writes:
> 
> > What do you mean the -d flag without the -X flags?
> > 
> > So, you can say -dX and those WD drives that froze
> the system before would 
> > work?
> 
> nope, froze anyway here :(
> 


=

Eugenio Diaz, BSEE/BSCE   
Linux Engineer
[EMAIL PROTECTED]

__
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/




Re: [Cooker] Install from running environment?

2000-06-19 Thread ckmb


> > Is there a a way to install 7.1 from within a running version of
> > linux if it is already running the same kernel? I don't see any
> > problem with this but I don't know how to do it.
>
> you mean upgrade ???
>
Yes and no.

There are some machines which I can get the hardware working but
refuse to do so as part of the standard install. I'd like to set up
the loaded modules and networking etc.. and then do an install or an
upgrade. I don't care if it has to remount the filesystems in read
only.




RE: [Cooker] U66 solved

2000-06-19 Thread Eugenio Diaz

Are you specifiying the two flags at the same time in
the same command? If not, you have to.

What drives do you have?

The controller mode may also have to be set, most
don't. With my Promise U66 I don't have to.

--- "B. K. Barley" <[EMAIL PROTECTED]> wrote:
> I have reported the same problem even with the -X
> option.  I've tried
> various settings on the X flag and when I turned on
> DMA Transfer, it would
> crash also.
> 
> B. K. Barley

=

Eugenio Diaz, BSEE/BSCE   
Linux Engineer
[EMAIL PROTECTED]

__
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/




Re: [Cooker] U66 solved

2000-06-19 Thread Eugenio Diaz

Nope, this are just MFG. ID strings being read by the
kernel from the devices.

--- bobby dowling <[EMAIL PROTECTED]> wrote:
> What if you see this at boot-up:
> 
> HPT366: onboard version of chipset, pin1=1 pin2=2
> PCI: HPT366: Fixing interrupt 11 pin 2 to ZERO
> HPT366: IDE controller on PCI bus 00 dev 98
> HPT366: not 100% native mode: will probe irqs later
> ide2: BM-DMA at 0xb800-0xb807, BIOS settings:
> hde:DMA, hdf:pio
> HPT366: IDE controller on PCI bus 00 dev 99
> HPT366: not 100% native mode: will probe irqs later
> ide3: BM-DMA at 0xc400-0xc407, BIOS settings:
> hdg:DMA, hdh:pio
> hda: CD-ROM 45X, ATAPI CDROM drive
> hdc: YAMAHA CRW8424E, ATAPI CDROM drive
> hde: Maxtor 51536U3, ATA DISK drive
> hdg: WDC WD136BA, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0xb000-0xb007,0xb402 on irq 11
> ide3 at 0xbc00-0xbc07,0xc002 on irq 11
> hde: Maxtor 51536U3, 14655MB w/2048kB Cache,
> CHS=29777/16/63, UDMA(66)
> hdg: WDC WD136BA, 13042MB w/1961kB Cache,
> CHS=26500/16/63, UDMA(66)
> 
> 
> Doesn't this mean that Dma is already turned on?


=

Eugenio Diaz, BSEE/BSCE   
Linux Engineer
[EMAIL PROTECTED]

__
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/




Re: [Cooker] Wheel mouse support in 7.1/Cooker

2000-06-19 Thread Roberto Rosselli Del Turco

David BAUDENS wrote:
> 
> root écrivit :
> 
> [...]
> 
> > 1. it works with Netscape and other Motif applications (Nedit), but the
> > scrolling is worse (i.e. rough, not smooth as before);
> > 2. it still works in most GNOME applications, but the scrolling is worse
> > (idem, add a really annoying 'circular' scrolling);
> > 3. it stopped working, or works partially, in some GTK/GNOME working
> > applications (e.g. gentoo, I can't scroll my shortcuts anymore);
> > 4. it most definitely stopped working with WINGs windows;
> > 5. it most definitely stopped working with aterm;
> > 6. it still doesn't work with KDE applications.
> 
> [...]
> 
> Have you launch Imwheel? Wheel work fines in all applications with it.

Actually, I think imwheel is the culprit: it sure doesn't deliver what
promised. So, waiting for a better understanding of how it works, I'd
like to disable it: can I safely uninstall it or is it better to comment
it out (what's the script in question?)? 

I must say I am mildly disappointed with this release, mainly because of
details like this; even Netscape is behaving funny, when I launch it the
window is blank and useless for about 5 minutes, then it comes to life:
never seen this before, abrupt termination was the norm :)

Mind you: it still is one of the best, if not the best, Linux
distribution IMHO. Just needing some refining here and there.

> --
> MandrakeSofthttp://www.mandrakesoft.com
> PARIS, FRANCE   --David
 
Ciao

-- 
Roberto Rosselli Del Turco  e-mail: [EMAIL PROTECTED]
Dipartimento di Scienze [EMAIL PROTECTED]
del Linguaggio  Then spoke the thunder  DA
Universita' di Torino   Datta: what have we given?  (TSE)
 
  Hige sceal the heardra, heorte the cenre,
  mod sceal the mare,   the ure maegen litlath.  (Maldon 312-3)





Re: [Cooker] corrupt RPM database, what then?

2000-06-19 Thread Stefan van der Eijk

Oh oh oh... a little panic from van der Eijk again...
I'm starting to feel guilty...

> > > rpm -Uvh gnome-libs-1.2.1-2mdk.alpha.rpm
> > > error: failed dependencies:
> > > libart_lgpl.so.2 is needed by ee-0.3.11-5mdk
> > > libart_lgpl.so.2 is needed by libglade-0.13-1mdk
> > > libart_lgpl.so.2 is needed by gnome-media-1.0.51-3mdk
> > > libart_lgpl.so.2 is needed by gnome-linuxconf-0.23-2mdk
> > > libart_lgpl.so.2 is needed by gtop-1.0.7-0.4mdk
> > > libart_lgpl.so.2 is needed by gnomba-0.6.2-4mdk

> Perform a "rpm -q{p}i --provides" on both gnome-libs 1mdk and 2mdk

> You'll see that the 1mdk does provide libart_lgpl whereas 2mdk won't
> probably provide it (even if the file list contains this file!)
It's even worse...

glibc
x86 alpha
glibc-localedataglibc-localedata
ANSI_X3.110.so  ld.so.2
ARMSCII-8.so
ASMO_449.so
BIG5.so
CP1250.so
CP1251.so
CP1252.so
CP1253.so
CP1254.so
CP1255.so
CP1256.so
CP1257.so
CP1258.so
CP737.so
CP775.so
CSN_369103.so
CWI.so
DEC-MCS.so
EBCDIC-AT-DE-A.so
EBCDIC-AT-DE.so
EBCDIC-CA-FR.so
EBCDIC-DK-NO-A.so
EBCDIC-DK-NO.so
EBCDIC-ES-A.so
EBCDIC-ES-S.so
EBCDIC-ES.so
EBCDIC-FI-SE-A.so
EBCDIC-FI-SE.so
EBCDIC-FR.so
EBCDIC-IS-FRISS.so
EBCDIC-IT.so
EBCDIC-PT.so
EBCDIC-UK.so
EBCDIC-US.so
ECMA-CYRILLIC.so
EUC-CN.so
EUC-JP.so
EUC-KR.so
...
..
.
and the list goes on...

Something went very wrong on my alpha... the Glibc package it produces
doesn't provide much... hmmm

> This is due to problems while building the new RPM. Try to monitor the
> rebuild of the new RPM and see why the "find provides" probably fails to
> complete gracefully..

Small bit from the glibc buildoutput:

Failed to find Provides:
Provides: glibc-localedata ld.so.2
PreReq: /sbin/ldconfig
Obsoletes: zoneinfo libc-static libc-devel libc-profile libc-headers
linuxthreads gencat locale glibc-localedata
Processing files: glibc-devel-2.1.3-7mdk
Finding  Provides: (using /usr/lib/rpm/find-provides)...
line 532: Dependency tokens must begin with alpha-numeric, '_' or '/': -
first build for 2.0.96

See... I'm feeling _so_ guilty... all of the packages on my alpha have
this
problem... Now, I'm really wondering WTF caused this...

greetz,

Stefan




Re: [Cooker] Mylex RAID controllers, and Adaptec ones too

2000-06-19 Thread Pixel

Derek Wildstar <[EMAIL PROTECTED]> writes:

> > > I have a machine with a Mylex DAC960 and an adaptec, the initial probe
> > > sees the adaptec, then I answer "yes" for more scsi controllers, select
> > > Mylex DAC960 from the list, hit OK and it finds it.  I was in an
> > > Expert/Development installation.
> > 
> > can you give the output of lspcidrake?
> 
> Here goes =)  Probably much more output than needed, but better more than
> less.

[...]

> Mylex Corporation|DAC960PX (STORAGE_RAID DAC960)

thanks a lot, got the pb. Tis STORAGE_RAID instead of STORAGE_SCSI. I changed
the regexp and that's it :)

now, more autodetection...


cu Pixel.




Re: [Cooker] U66 solved

2000-06-19 Thread bobby dowling

What if you see this at boot-up:

HPT366: onboard version of chipset, pin1=1 pin2=2
PCI: HPT366: Fixing interrupt 11 pin 2 to ZERO
HPT366: IDE controller on PCI bus 00 dev 98
HPT366: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xb800-0xb807, BIOS settings: hde:DMA, hdf:pio
HPT366: IDE controller on PCI bus 00 dev 99
HPT366: not 100% native mode: will probe irqs later
ide3: BM-DMA at 0xc400-0xc407, BIOS settings: hdg:DMA, hdh:pio
hda: CD-ROM 45X, ATAPI CDROM drive
hdc: YAMAHA CRW8424E, ATAPI CDROM drive
hde: Maxtor 51536U3, ATA DISK drive
hdg: WDC WD136BA, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xb000-0xb007,0xb402 on irq 11
ide3 at 0xbc00-0xbc07,0xc002 on irq 11
hde: Maxtor 51536U3, 14655MB w/2048kB Cache, CHS=29777/16/63, UDMA(66)
hdg: WDC WD136BA, 13042MB w/1961kB Cache, CHS=26500/16/63, UDMA(66)


Doesn't this mean that Dma is already turned on?


>From: Eugenio Diaz <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: [Cooker] U66 solved
>Date: Sun, 18 Jun 2000 22:47:53 -0700 (PDT)
>MIME-Version: 1.0
>Received: from [216.71.84.35] by hotmail.com (3.2) with ESMTP id 
>MHotMailBB16FF6F0062D820F3C8D84754234A0B0; Sun Jun 18 22:49:35 2000
>Received: (from sympa@localhost)by mandrakesoft.mandrakesoft.com 
>(8.8.5/8.8.5) id AAA00834for [EMAIL PROTECTED]; Mon, 19 Jun 2000 
>00:48:51 -0500
>Received: from web121.yahoomail.com (web121.yahoomail.com
>[205.180.60.129]) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP  
>   id AAA00302 for <[EMAIL PROTECTED]>; Mon, 19 Jun 2000 00:47:13   
>  -0500
>Received: (qmail 14189 invoked by uid 60001); 19 Jun 2000 05:47:53 -
>Received: from [207.36.26.197] by web121.yahoomail.com; Sun,18 Jun 2000 
>22:47:53 PDT
>From [EMAIL PROTECTED] Sun Jun 18 22:51:13 2000
>Message-Id: <[EMAIL PROTECTED]>
>X-Loop: [EMAIL PROTECTED]
>X-Sequence: 1232
>Precedence: list
>
>
>--- bobby dowling <[EMAIL PROTECTED]> wrote:
> > What do you mean the -d flag without the -X flags?
> >
> > So, you can say -dX and those WD drives that froze
> > the system before would
> > work?
>
>Nooo! For UltraDMA2 on your fisrst ide drive, it would
>be something like this (for an explanation of the
>number after the -X, see the man page of hdparm):
>
>hdparm -d1 -X66 /dev/hda
>
>or for an older EIDE drive:
>
>hdparm -d1 -X34 /dev/hda
>
>**Please note this is dangerous stuff; if you punch in
>a mode that does not corresponds to what your
>drive/controller is capable, under some circumstances
>it could lead to a corrupted file systems.
>
>=
>
>Eugenio Diaz, BSEE/BSCE
>Linux Engineer
>[EMAIL PROTECTED]
>
>__
>Do You Yahoo!?
>Send instant messages with Yahoo! Messenger.
>http://im.yahoo.com/
>


Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com




Re: [Cooker] What are the latest support packages needed for KDE2?

2000-06-19 Thread Guillaume Rousse

Try at ftp://ftp.sunet.se/pub/Linux/distributions/mandrake-crypto/7.1/

Also sprach lun, 19 jun 2000 :
> - Original Message -
> From: "Christopher Molnar" <[EMAIL PROTECTED]>
> To: "Hoyt" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Monday, June 19, 2000 1:08 PM
> Subject: Re: [Cooker] What are the latest support packages needed for KDE2?
> 
> 
> >
> > you need qt2.1.1 and you need openssl.
> >
> > -Chris
> 
> I see no openssl package in cooker. I am using the rpmfind.net mirror. Will
> the openssl rpm package for SuSE work or should I compile from source?
> 
> Hoyt
-- 
Guillaume Rousse
Iremia - Université de la Réunion

Sleep doesn't exists. Just lack of cafeine.




Re: [Cooker] Mylex RAID controllers, and Adaptec ones too

2000-06-19 Thread Derek Wildstar

> > I have a machine with a Mylex DAC960 and an adaptec, the initial probe
> > sees the adaptec, then I answer "yes" for more scsi controllers, select
> > Mylex DAC960 from the list, hit OK and it finds it.  I was in an
> > Expert/Development installation.
> 
> can you give the output of lspcidrake?

Here goes =)  Probably much more output than needed, but better more than
less.

-dwild



[root@foghorn dwild]# lspcidrake
Intel Corporation|440GX - 82443GX Host bridge (unknown ignore)
Intel Corporation|440GX - 82443GX AGP bridge (unknown ignore)
Adaptec|7896 (STORAGE_SCSI aic7xxx)
Adaptec|7896 (STORAGE_SCSI aic7xxx)
Intel Corporation|82557 [Ethernet Pro 100] (NETWORK_ETHERNET eepro100)
Intel Corporation|82371AB PIIX4 ISA (unknown unknown)
Intel Corporation|82371AB PIIX4 IDE (STORAGE_IDE unknown)
Intel Corporation|82371AB PIIX4 USB (SERIAL_USB usb-uhci)
Intel Corporation|82371AB PIIX4 ACPI (unknown unknown)
Cirrus Logic|GD 5480 (DISPLAY_VGA Card:Cirrus Logic GD5480)
DEC|DECchip 21150 (unknown unknown)
Intel Corporation|80960RP [i960 RP Microprocessor/Bridge] (unknown
unknown)
Mylex Corporation|DAC960PX (STORAGE_RAID DAC960)
[root@foghorn dwild]# lspci
00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge
00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge
00:0c.0 SCSI storage controller: Adaptec 7896
00:0c.1 SCSI storage controller: Adaptec 7896
00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100]
(rev 08)
00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23)
01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06)
02:07.0 PCI bridge: Intel Corporation 80960RP [i960 RP
Microprocessor/Bridge] (rev 03)
02:07.1 RAID bus controller: Mylex Corporation DAC960PX (rev 03)
[root@foghorn dwild]# lspci -vvv
00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- 

00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge (prog-if
00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- Reset- FastB2B+

00:0c.0 SCSI storage controller: Adaptec 7896
Subsystem: Adaptec: Unknown device 080f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- Reset- FastB2B-
Capabilities: [dc] Power Management version 1
Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

02:07.0 PCI bridge: Intel Corporation 80960RP [i960 RP
Microprocessor/Bridge] (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B+
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- Reset- FastB2B-

02:07.1 RAID bus controller: Mylex Corporation DAC960PX (rev 03)
Subsystem: Mylex Corporation: Unknown device 0010
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B+
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- 


Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Frank Meurer


On Mon, 19 Jun 2000, Bryan Paxton wrote:

> I've talked to a lot of ex-mandrake users who switched to debian simply for apt,
> and who also said they wouldn't gladly switch back if RPM was hacked up to be
> more robust, flexiable, and reliable as deb(dpkg,apt). 

Er... rpm *is* IMHO more flexible than deb*.
AFAIK the deb packages are only simple ar-archives with simple shell-
scripts for de-/installation. Maybe this has changed meanwhile, don't know.
RPM offers a set of powerful macros which are easy to use but also give
complete control and offer more information about a package and its
dependencies. RPM offers you also simple control of compiler options
at build time (e.g. i386, i486 etc.)

When I decided to use a package system for managing my private programs
and tools I looked at .deb and .rpm and decided to use the more powerful
rpm package system.

And please remember:
A package is always as good as its creator! ;-)

Just my $0.02

-
Windows users go to Gates heaven, Linux users go everywhere !

Sending unsolicited commercial email to this address may be a violation
of the Washington State Consumer Protection Act, chapter 19.86 RCW.
Das Verschicken unverlangter kommerzieller email an diese Adresse ist
verboten (LG Traunstein, 2 HK O 3755/97 vom 14.10.1997, CR 1998, 171f).

(Frank Meurer, <[EMAIL PROTECTED]>, PGP ID: 0x5E756DA8)





Re: [Cooker] What are the latest support packages needed for KDE2?

2000-06-19 Thread Hoyt


- Original Message -
From: "Christopher Molnar" <[EMAIL PROTECTED]>
To: "Hoyt" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, June 19, 2000 1:08 PM
Subject: Re: [Cooker] What are the latest support packages needed for KDE2?


>
> you need qt2.1.1 and you need openssl.
>
> -Chris

I see no openssl package in cooker. I am using the rpmfind.net mirror. Will
the openssl rpm package for SuSE work or should I compile from source?

Hoyt





[Cooker] KDE and french characters

2000-06-19 Thread Denis Pelletier

Hello,

I´ve installed Mandrake 7.1 a few days ago and I´m unable to type french
characters in any KDE-aware application. My keyboard layout is US
english. In every KDE-unaware application (emacs, gEdit, ...) I can type
"ê" by using Alt_R + "^" and "e". But with KDE application, the same
sequence gives me "^e".

I'm not using the international keyboard module. Is it a bug in KDE? Can I
force KDE to use my settings for X? Is it only a matter of editing a
config file?

Before installing Mandrake 7.1, I was using RedHat 6.1 (with the same
XF86Config) and I did not had this problem.

Thanks.

Denis

-- 
___
Denis Pelletier
Étudiant au doctorat
sciences économiques, Université de Montreal





Re: [Cooker] SHOW-STOPPER: Cannot export file systems with 7.1

2000-06-19 Thread David Walluck

On Mon, 19 Jun 2000, Quel Qun wrote:

> I cannot believe that!
> I reported this conflict between nfs-client and quota at least a thousand 
> million times!
> So if cooker members are so valuable, then don't loose our reports.
> 

I have felt this way too. Ei ther report a bug and have it ignored, or
worse, be told that for some reason it is supposed to be that way. I
really think a) all bugs reported that aren't going to be immediately
addressed should be put in a todo pile, and someone should reply that the
bug has been noted b) if the package maintainer somehow claims it is not a
bug, someone else, or maybe at least a few people, should also respond as
to whther it is a bug or not. Somtimes it is because they have no
intention of fixing it for that release, and ignore the report. Still, as
I said in a) ignoring it for the time being doesn't mean you have to
ignore the message alltogether.




Re: [Cooker] What are the latest support packages needed for KDE2?

2000-06-19 Thread Guillaume Rousse

And what about libasound.so.1 which i found only in alsalibs ?

Also sprach lun, 19 jun 2000 :
> you need qt2.1.1 and you need openssl.
> 
> -Chris
> 
> 
> On Mon, 19 Jun 2000, Hoyt wrote:
> 
> > I have downloaded the KDE2 rpms from cooker contribs. The addition of the
> > scripts rpm is wonderful. Thanks.
> > 
> > What other packages do I need to install KDE2 on my M7.1 system? QT 2.x
> > packages from cooker? Any others that the kde*2- packages depends on?
> > 
> > Hoyt
-- 
Guillaume Rousse
Iremia - Université de la Réunion

Sleep doesn't exists. Just lack of cafeine.




Re: [Cooker] SHOW-STOPPER: Cannot export file systems with 7.1

2000-06-19 Thread Quel Qun

>From: Warly <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: [Cooker] SHOW-STOPPER: Cannot export file systems with 7.1
>Date: 18 Jun 2000 12:32:08 +0200
>
>
> > The nsf-utils RPM includes the essential file /usr/sbin/exportfs
> > without the execution of which no mount points may be exported so
> > that nfs mounts can not be made.
> >
> > An attempt to manually install nfs-utils from the 7.1 tree led to:
> >
> > file /usr/sbin/rpc.rquotad from install of nfs-utils-0.1.7-2mdk
> > conflicts with file from package quota-1.66-11mdk
> >
> > and nfs-utils will not install, even with all the overrides.
>
>Yes you r right nfs-utils conflicts with quota, this gonna be
>corrected.
>
>This is our fault but it is hard to test all the combination of
>installed packages, and this is why you, cooker members, are so
>precious to us.
>

I cannot believe that!
I reported this conflict between nfs-client and quota at least a thousand 
million times!
So if cooker members are so valuable, then don't loose our reports.

Sorry for the grunt, but I can't help it.

Now the (nice) show must go on.
=-=
kk1

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com




Re: [Cooker] What are the latest support packages needed for KDE2?

2000-06-19 Thread Christopher Molnar


you need qt2.1.1 and you need openssl.

-Chris


On Mon, 19 Jun 2000, Hoyt wrote:

> I have downloaded the KDE2 rpms from cooker contribs. The addition of the
> scripts rpm is wonderful. Thanks.
> 
> What other packages do I need to install KDE2 on my M7.1 system? QT 2.x
> packages from cooker? Any others that the kde*2- packages depends on?
> 
> Hoyt
> 
> 
> 




RE: [Cooker] Cooker Cleaner needed

2000-06-19 Thread Armisis Aieoln

Thanks all!!! Ill have to get that stuff working... im waisting too much
harddrive space as is 

thanx again

dave


On Sun, 18 Jun 2000, you wrote:
> Depends on how you actually perform the mirroring.  A good mirror tool
> (fmirror?) should do it.
> 
> I personally use rsync.  There's an option in rsync that will delete any
> files that no longer exist on the master site.  I think I use something like
> the following..
> 
> rsync -av --progress --delete --exclude "*.src.rpm"
> rsync://blah.com/Mandrake-devel /mirror/Mandrake-devel
> 
> (That is all one big line..)
> 
> To break that down..
> -av  =  Archive and verbose mode
> --progress  =  Show me what's going on
> --delete  =  Delete packages that no longer exist
> --exclude "*.src.rpm"  =  I don't want source RPMs
> rsync://blah.com/Mandrake-devel  =  The server and tree I'm mirroring
> /mirror/Mandrake-devel  =  Where I'm keeping the mirror locally
> 
> Works like a charm. =)
> 
> Don Head
> Linux Mentor
> Wave Technologies, Inc.
> [EMAIL PROTECTED]
> 
> 
> -Original Message-
> From: Armisis Aieoln
> To: [EMAIL PROTECTED]
> Sent: 6/18/00 1:33 PM
> Subject: [Cooker] Cooker Cleaner needed
> 
> Hello again all, Just writing to see if anyone can suggest a utility for
> cleaning out old versions of my RPMS/files from my
> /Mandrake-devel/cooker
> directory... The more I upgrade the more old stuff gets left behind and
> I have
> to manualy get in there and root arround for stuff that is no longer
> needed or
> outdated.  I was hoping some one has already addressed this issue but If
> not I
> would love to try to make a script or something to do the job, but I
> dont know
> where to begin in writing such a tool.
> 
> Dave
> 
>  --  [EMAIL PROTECTED]
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> LINUX - Why?
> Cause I dont do windows
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-- 
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
LINUX - Why?
Cause I dont do windows
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=




[Cooker] problems with new Mesa package ?

2000-06-19 Thread Guillaume Rousse

I  was quite a bit surprised when X refused to start anymore just after
installing imwheel. After a few inquiries, the responsability was to recently
installed new Mesa 3.2 packages. There must be a conflict either with XFree 4
or with my Voodoo card at startup, but i can't say more. I can send my log file
if someone is interested in this topic.

 -- 
Guillaume Rousse
Iremia - Université de la Réunion

Sleep doesn't exists. Just lack of cafeine.




[Cooker] What are the latest support packages needed for KDE2?

2000-06-19 Thread Hoyt

I have downloaded the KDE2 rpms from cooker contribs. The addition of the
scripts rpm is wonderful. Thanks.

What other packages do I need to install KDE2 on my M7.1 system? QT 2.x
packages from cooker? Any others that the kde*2- packages depends on?

Hoyt





RE: [Cooker] U66 solved

2000-06-19 Thread B. K. Barley

I have reported the same problem even with the -X option.  I've tried
various settings on the X flag and when I turned on DMA Transfer, it would
crash also.

B. K. Barley

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 19, 2000 5:13 AM
To: [EMAIL PROTECTED]
Subject: Re: [Cooker] U66 solved


"bobby dowling" <[EMAIL PROTECTED]> writes:

> What do you mean the -d flag without the -X flags?
>
> So, you can say -dX and those WD drives that froze the system before would
> work?

nope, froze anyway here :(





Re: [Cooker] U66 solved

2000-06-19 Thread tracer

Hello Pixel,
On 19 Jun 2000 11:12:38 +0200 GMT your local time,
which was Monday, June 19, 2000, 4:12:38 PM (GMT+0700) my local time,
Pixel wrote:


> "bobby dowling" <[EMAIL PROTECTED]> writes:

>> What do you mean the -d flag without the -X flags?
>> 
>> So, you can say -dX and those WD drives that froze the system before would 
>> work?

> nope, froze anyway here :(

Now a more intriguing question is, has anyone tried to replace these
drives under waranty as being out of spec???
They claim to be UDMA66 and they donot run properly so what about
getting ones money back...





-- 

Best regards,
 
tracer

Using theBAT 1.44 

mail to : [EMAIL PROTECTED]
using FireTalk: 321338
LOCAL phone: 271194





Re: [Cooker] Install from running environment?

2000-06-19 Thread Ron Stodden

Pixel wrote:
> 
> [EMAIL PROTECTED] writes:
> 
> > Is there a a way to install 7.1 from within a running version of
> > linux if it is already running the same kernel? I don't see any
> > problem with this but I don't know how to do it.
> 
> you mean upgrade ???

I imagine he means the ability to install Linux on to a new partition
while running a (presently non-existent) version of DrakX from
another running Linux partition.

The big advantage of such a facility would be the removal of the
requirement to dedicate the entire machine exclusively to the
installation job for an hour or so.   You could then set the install
going, perhaps as a background process, and continue with your normal
Linux activities (like web surfing, messaging, game playing, watching
television, beta testing, or even application development) while the
install to another partition is going on.  Of course rpm would need
the ability to operate on a specified mounted partition rather than
the present default assumption of the currently running Linux
partition.

In these times of cheap hard disk space, this approach makes great
sense, and might IMO have been a much easier starting point for
developing an installer.  It is of course no good for doing the very
first Linux install - but maybe eg tomsrtbt might provide enough
platform to run such an installer?

-- 

Regards,

Ron. [AU] - sent by Mandrake Linux.




Re: [Cooker] SHOW-STOPPER: Cannot export file systems with 7.1

2000-06-19 Thread Ron Stodden

David Foresman wrote:
> 
> >From all my testing.  The crypto works fine from within IPmasq if you have a
> static IP on your inside box (192.168.1.x).  I setup a dhcp server on my
> masq box and received my address internally via dhcp, and i got the Bad Peer
> Address error during crypto install.

Both the inside machines IP addresses and the external gateway
(cable) IP address are all fixed addresses.  

During install on the masq'd machine I gave the dotted quad address
of the gateway machine to the installer.   

The installer neglects to collect the information necessary to be
able to set up /etc/hosts and /etc/nsswitch.   Also neglects to set
up /etc/lpd, without which how can the test of a remote printer ever
succeed?Perhaps one day ...

-- 

Regards,

Ron. [AU] - sent by Mandrake Linux.




Re: [Cooker] SHOW-STOPPER: Cannot export file systems with 7.1

2000-06-19 Thread Ron Stodden

Civileme wrote:
> 
> To  suggest a possible reason
> 
> Active vs passive ftp--I think the install is using Active FTP port commands
> at that point..  I have experienced the same when behind a masquerading
> firewall.  And I don't use anything beyond the three-line masquerade for my
> firewalling  (plus a few recognition-and-response daemons of my own devising,
> which I had turned off),

Without a firewall, active or passive should make no difference? 
Active requires the ability for the remote server to make a TCP SYN
connection to the client (but the firewall prevents incoming TCP
connections).

With the gateway firewall down, except for masquerading, I still have
the 

/sbin/modprobe ip_masq_ftp 

module loaded.  Significant?   Dunno.

-- 

Regards,

Ron. [AU] - sent by Mandrake Linux.




Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Guillaume Cottenceau

Bryan Paxton <[EMAIL PROTECTED]> writes:

> But what are the drawbacks ? Are there any at all ?

1. We have to be Redhat-compatible.
2. Our whole pool of software has long been made with rpm specfiles.
3. RPM is more widely known and used.
4. deb format is not so much superior to rpm format.

-- 
Guillaume Cottenceau




Re: [Cooker] fetchmail-5.4.0-1mdk.i586.rpm hangs

2000-06-19 Thread Guillaume Cottenceau

"Geoffrey Lee" <[EMAIL PROTECTED]> writes:

> > Sent: Sunday, June 18, 2000 9:33 AM
> > To: [EMAIL PROTECTED]
> > Subject: [Cooker] fetchmail-5.4.0-1mdk.i586.rpm hangs
> > 
> > 
> > Hi to all.
> > 
> > I noticed that also Mandrake 7.1 is affected by mysterious hangs of
> > Red Hat 6.2 [ http://www.tuxedo.org/~esr/fetchmail/NEWS ].
> > 
> 
> 
> 
> 
> 
> ALSO there is a license problem, license is GPL not distributable

fixing it.

-- 
Guillaume Cottenceau




Re: [Cooker] Many packages suddenly not building.... (looks ugly)

2000-06-19 Thread Guillaume Cottenceau

Chmouel Boudjnah <[EMAIL PROTECTED]> writes:

> Chmouel Boudjnah <[EMAIL PROTECTED]> writes:
> 
> > Stefan van der Eijk <[EMAIL PROTECTED]> writes:
> > 
> > > Anyway, if you're building packages it might be better to stay off of 
> > > the latest rpm for a while, until the water has cleared ;-) 
> > > Chmouel, agree?
> > 
> > Hugh i didn't any major thing in the API of rpmlib.
> 
> humm ok it's the change to the %configure macros, now to fix this use
> the %makeinstall in the spec file, rather of :
> 
> make install prefix=foo this=bar
> 
> %makeinstall should do the job.

Yes but we need to know *why* this happens, in order to compile the
software which won't support the %makeinstall script..

-- 
Guillaume Cottenceau




Re: [Cooker] SHOW-STOPPER: Cannot export file systems with 7.1

2000-06-19 Thread David Foresman

>From all my testing.  The crypto works fine from within IPmasq if you have a
static IP on your inside box (192.168.1.x).  I setup a dhcp server on my
masq box and received my address internally via dhcp, and i got the Bad Peer
Address error during crypto install.


- Original Message -
From: "Civileme" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 19, 2000 6:01 AM
Subject: Re: [Cooker] SHOW-STOPPER: Cannot export file systems with 7.1


> On Sun, 18 Jun 2000, you wrote:
> > Graham Percival wrote:
> >
> > > Really?  I've never had problems installing crypto RPMs on my
> > > masq'ed internal network.  Maybe you configured your NAT / firewall
> > > incorrectly.
> >
> > Same problem even with the gateway machine firewall taken down
> > (except for masquerading).
> >
> > Error box is:
> >
> > An error occurred
> > Net::FTP: Bad peer adddress ...propagated.
> >
> > The install then loops around repeatedly trying the crypto
> > download.   I have to hit a lower star to recover.
> >
> > This occurs on any choice of mirror, and is quite uninformative to me
> > on what the error was and what needs to be done to fix it.
> >
> > --
> >
> > Regards,
> >
> > Ron. [AU] - sent by Mandrake Linux.
>
> To  suggest a possible reason
>
> Active vs passive ftp--I think the install is using Active FTP port
commands
> at that point..  I have experienced the same when behind a masquerading
> firewall.  And I don't use anything beyond the three-line masquerade for
my
> firewalling  (plus a few recognition-and-response daemons of my own
devising,
> which I had turned off),
>
> Civileme
>
>




Re: [Cooker] corrupt RPM database, what then?

2000-06-19 Thread Guillaume Cottenceau

Stefan van der Eijk <[EMAIL PROTECTED]> writes:

> > rpm -Uvh gnome-libs-1.2.1-2mdk.alpha.rpm
> > error: failed dependencies:
> > libart_lgpl.so.2 is needed by ee-0.3.11-5mdk
> > libart_lgpl.so.2 is needed by libglade-0.13-1mdk
> > libart_lgpl.so.2 is needed by gnome-media-1.0.51-3mdk
> > libart_lgpl.so.2 is needed by gnome-linuxconf-0.23-2mdk
> > libart_lgpl.so.2 is needed by gtop-1.0.7-0.4mdk
> > libart_lgpl.so.2 is needed by gnomba-0.6.2-4mdk

Stefan,

Perform a "rpm -q{p}i --provides" on both gnome-libs 1mdk and 2mdk

You'll see that the 1mdk does provide libart_lgpl whereas 2mdk won't
probably provide it (even if the file list contains this file!)

This is due to problems while building the new RPM. Try to monitor the
rebuild of the new RPM and see why the "find provides" probably fails to
complete gracefully..


-- 
Guillaume Cottenceau




Re: [Cooker] CD vs FTP download

2000-06-19 Thread Guillaume Cottenceau

"Steven J Mackenzie" <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I'm a bit confused by the new larger Mandrake distribution.
> 
>  I download my Mandrake cooker over a 64K ISDN line. Because I download from
> the ftp site, it doesn't matter if the download gets interupted, for instace
> by a new RPM going in to the archive. When it's finished I can resync the
> archive, run mkhdlist, and burn it to CD
> 
> But I can't do this anymore as all the RPMS are in one directory, so it's
> too big for a CD. (It's also too big for the parittion I download to !)
> 
> Is it possible to split the "extra"  RPMS in to a seperate directory to make
> it easier to build my CDs?

We cannot do this; because it would revert to the problem we had the last
15 days, the FTP install will hang waiting for you to "change the media"..

You have several solutions:

. d/l an ISO image
. install via FTP
. split the rpm's in two separate directories; use the "rpmslist" file for
  that.


-- 
Guillaume Cottenceau




Re: [Cooker] Mylex RAID controllers, and Adaptec ones too

2000-06-19 Thread Pixel

Alex Boag-Munroe <[EMAIL PROTECTED]> writes:

> Can I get this during installation?

yep:

% mount /dev/fd0 /fd0
% dmesg > /fd0/syslog
% lspci > /fd0/lspci
% cat /proc/bus/pci/devices > /fd0/pci
% umount /fd0

(using a fat formatted floppy)

[...]

> give your /proc/pci, lspcidrake, syslog...




Re: [Cooker] Wheel mouse support in 7.1/Cooker

2000-06-19 Thread Roberto Rosselli Del Turco

David BAUDENS wrote:
> 
> root écrivit :
> 
> [...]
> 
> > 1. it works with Netscape and other Motif applications (Nedit), but the
> > scrolling is worse (i.e. rough, not smooth as before);
> > 2. it still works in most GNOME applications, but the scrolling is worse
> > (idem, add a really annoying 'circular' scrolling);
> > 3. it stopped working, or works partially, in some GTK/GNOME working
> > applications (e.g. gentoo, I can't scroll my shortcuts anymore);
> > 4. it most definitely stopped working with WINGs windows;
> > 5. it most definitely stopped working with aterm;
> > 6. it still doesn't work with KDE applications.
> 
> [...]
> 
> Have you launch Imwheel? Wheel work fines in all applications with it.

If I'm not wrong, it's launched automatically at startup time.
 
> --
> MandrakeSofthttp://www.mandrakesoft.com
> PARIS, FRANCE   --David

Ciao

-- 
Roberto Rosselli Del Turco  e-mail: [EMAIL PROTECTED]
Dipartimento di Scienze [EMAIL PROTECTED]
del Linguaggio  Then spoke the thunder  DA
Universita' di Torino   Datta: what have we given?  (TSE)
 
  Hige sceal the heardra, heorte the cenre,
  mod sceal the mare,   the ure maegen litlath.  (Maldon 312-3)




RE: [Cooker] Mylex RAID controllers, and Adaptec ones too

2000-06-19 Thread Alex Boag-Munroe

Can I get this during installation?

-Original Message-
From: Pixel [mailto:[EMAIL PROTECTED]]
Sent: 19 June 2000 12:11
To: [EMAIL PROTECTED]
Cc: '[EMAIL PROTECTED]'
Subject: Re: [Cooker] Mylex RAID controllers, and Adaptec ones too


Alex Boag-Munroe <[EMAIL PROTECTED]> writes:

> Unfortunately, I was running in Expert mode, but still no joy.  Finds the
on
> board adaptec, but not interested in the DAC960

give your /proc/pci, lspcidrake, syslog...

> 
> -Original Message-
> From: Derek Wildstar [mailto:[EMAIL PROTECTED]]

[...]

> I have a machine with a Mylex DAC960 and an adaptec, the initial probe
> sees the adaptec, then I answer "yes" for more scsi controllers, select
> Mylex DAC960 from the list, hit OK and it finds it.  I was in an
> Expert/Development installation.
> 

give your /proc/pci, lspcidrake!

thanks, cu Pixel.

begin 600 winmail.dat
M>)\^(@L+`0:0"``$```!``$``0>0!@`(Y`0```#H``$(@`<`
M&$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06``P`.T`<&`!,`
M#``*``<``0`.`0$@@`,`#@```-`'!@`3``P`"@`'``$`#@$!"8`!`"$T
M1D)$-$-$03,S-#5$-#$Q.#8T,C`P-C`Y-S@R.$,S0@`)!P$$@`$`.@```%)%
M.B!;0V]O:V5R72!->6QE>"!204E$(&-O;G1R;VQL97)S+"!A;F0@061A<'1E
M8R!O;F5S('1O;P#J$P$-@`0``@(``@`!`Y`&`"P)```R`P`V
M```#``*`""`&``#`1@!2A0``)VH!`!X``X`((`8`
M`,!&`%2%```!!#DN,``+``2`""`&``#`
M1@`&A0,`!8`((`8``,!&``&%
M"P`!@`@@!@``P$8``X4+``:`""`&
M``#`1@`.A0,`!X`((`8``,!&
M`!"%`P`(@`@@!@``P$8`$84#``F`
M""`&``#`1@`8A0```!X`"H`((`8``,``
M``!&`#:%```!`0`>``N`""`&``#`1@``
M```WA0```0$`'@`,@`@@!@``P$8`.(4`
M``$!``(!"1`!+0,``"D#```-!0``3%I&=8V<0KD#``H`
M(R`T-T97@%00$#`??_"H`"I`/D!Q,"@`_S`%`$5C\(50>R$24.
M40,!`@!C:.$*P'-E=#(&``;#$27V,P1&$[V.Q@?#C`U$2(,
M8&,`4/,+"0%D,S864`NF$B`#D8A)(&<4("!T:`0`1"!D"'%N9R`+@'.E`9!L
M"V!T:0(@/PJBJPJ$"H`M'^)/!1!G"X#G!T`%T`>00RF\!@"X%H&U='R0&8`,","(@
M,3D@2G5N'&4@`=`EX"5`,CHQJQKS"H!4(P`@!:!O(^"("TCAI,D
M0A\D0V,B("=D`_`L;&0G="1")R25=6*F:@60)2%292(@6PA0926P.
MP`?P07Q)1"P")P>2UP'3!W.F$$('(ED`,`'B,@13QX<`20
M!4`$8BUP8G4/!4`><`,0`R!N;R!J0&]Y+B`@1@N`9/TN@6@EL`(@,Z8&X`L1
M+8#_+>0VU#>0!4`+@`ZP&"`><(<)@#7B.()$04,Y'#`K'RH@8'8EL'D(82`O
M2G`#8&,]L&-I+7!LCG,^$2.S+7!S>7,7L/QG+C^`,TPSIA_O(/TRL,4AY$0[
M`6L@5REQ'G'?!<`BIBE=)(4?)%L_@47[[S*P'3`3X#TQ83:``-`=H/\EH0/P
M'9!([EMAIL PROTECTED]'.((+@#+P!S$@/<%B_F4SIA00+G(XD4JZ'1(`<9)W
M$H$B>0>0(B`T0?`'G`M<+,=
MH`5`[EMAIL PROTECTED]@S?S+P-_$U%#7Q`'`SIC8D+_=#D#TP%[!P!X`",!Y+/Z7O
M0'8\OSW/(]$A'RH=D`!PLFLM86-U(C0_I7U=P!X`<``!-@```%M#
M;V]K97)=($UY;&5X(%)!240@8V]N=')O;&QEV;\!`P#Q/PD$```>`#%``08```!!3$580@``
M``,`&D``'@`P0`$&04Q%6$(#`!E```,`_3_D!```
M`P"`$/\"`4<``0```#<```!C/553.V$](#MP/4YO=F%T96-H.VP]24Y4
M15).151?4T525D4M,#`P-C$Y,3$Q,#`W6BTR.3<```(!^3\!40``
M``#`/H_`0```!$```!!;&5X($)O86V;\!0``(,&"3>^W>V;\!'@`]``$%
M4D4Z(``>`!T.`0```#8```!;0V]O:V5R72!->6QE>"!204E$(&-O
M;G1R;VQL97)S+"!A;F0@061A<'1E8R!O;F5S('1O;P```!X`-1`!00``
M`#Q#,40S,T1$-#)&-C=$,C$Q.#5%1#`P-C`P.#1$-S(R-S9!.$%%-D!M86EL
M:&]S="YN;W9A=&5C:"YC;RYU:SX`"P`I```+`",```,`!A#Y
M#-9G`P`'$+<"```#`!`0``,`$1`!'@`($`$```!E0T%.24=%
M5%1(25-$55))3D=)3E-404Q,051)3TX_+2TM+2U/4DE'24Y!3$U%4U-!1T4M
M+2TM+4923TTZ4$E814Q-04E,5$\Z4$E814Q`34%.1%)!2T533T940T]-4T5.
M5#HQ.0`"`7\``0```$$\0S%$,S-$1#0R1C8W1#(Q,3@U140P,#8P
M,#@T1#


Re: [Cooker] SHOW-STOPPER: Cannot export file systems with 7.1

2000-06-19 Thread Civileme

On Sun, 18 Jun 2000, you wrote:
> Graham Percival wrote:
> 
> > Really?  I've never had problems installing crypto RPMs on my
> > masq'ed internal network.  Maybe you configured your NAT / firewall
> > incorrectly.
> 
> Same problem even with the gateway machine firewall taken down
> (except for masquerading).
> 
> Error box is:
> 
> An error occurred
> Net::FTP: Bad peer adddress ...propagated.
> 
> The install then loops around repeatedly trying the crypto
> download.   I have to hit a lower star to recover.
> 
> This occurs on any choice of mirror, and is quite uninformative to me
> on what the error was and what needs to be done to fix it.
> 
> -- 
> 
> Regards,
> 
> Ron. [AU] - sent by Mandrake Linux.

To  suggest a possible reason

Active vs passive ftp--I think the install is using Active FTP port commands
at that point..  I have experienced the same when behind a masquerading
firewall.  And I don't use anything beyond the three-line masquerade for my
firewalling  (plus a few recognition-and-response daemons of my own devising,
which I had turned off),

Civileme




Re: [Cooker] Mylex RAID controllers, and Adaptec ones too

2000-06-19 Thread Pixel

Alex Boag-Munroe <[EMAIL PROTECTED]> writes:

> Unfortunately, I was running in Expert mode, but still no joy.  Finds the on
> board adaptec, but not interested in the DAC960

give your /proc/pci, lspcidrake, syslog...

> 
> -Original Message-
> From: Derek Wildstar [mailto:[EMAIL PROTECTED]]

[...]

> I have a machine with a Mylex DAC960 and an adaptec, the initial probe
> sees the adaptec, then I answer "yes" for more scsi controllers, select
> Mylex DAC960 from the list, hit OK and it finds it.  I was in an
> Expert/Development installation.
> 

give your /proc/pci, lspcidrake!

thanks, cu Pixel.




Re: [Cooker] Wheel mouse support in 7.1/Cooker

2000-06-19 Thread Christopher Gallant

it's trakman marble plus

On Mon, 19 Jun 2000, you wrote:
> Christopher Gallant écrivit :
>  
> > You guys can get mouse wheel to work? damn mine doesnt i have the logitech
> > with the thumb marble, And i have launced Imwheel too no scroll
>
> 
> ? What is the name of this mouse (it's write under the mouse).
> 
> -- 
> MandrakeSofthttp://www.mandrakesoft.com
> PARIS, FRANCE   --David




RE: [Cooker] Mylex RAID controllers, and Adaptec ones too

2000-06-19 Thread Alex Boag-Munroe

Unfortunately, I was running in Expert mode, but still no joy.  Finds the on
board adaptec, but not interested in the DAC960

-Original Message-
From: Derek Wildstar [mailto:[EMAIL PROTECTED]]
Sent: 17 June 2000 3:54
To: [EMAIL PROTECTED]
Subject: Re: [Cooker] Mylex RAID controllers, and Adaptec ones too


On Sat, 17 Jun 2000, Alberto Passariello wrote:

> > > Does anyone know why I can't get Mandrake 7.1 to acknowledge my Mylex
RAID
> > > controller?  It is in the list, but won't see it, it only sees my
Adaptec
> > > 2940.
> >
> > strange, it should work. 7.0 had a pb and patch fixed it... 7.1 has the
> > patch
> > already

I have a machine with a Mylex DAC960 and an adaptec, the initial probe
sees the adaptec, then I answer "yes" for more scsi controllers, select
Mylex DAC960 from the list, hit OK and it finds it.  I was in an
Expert/Development installation.

-dwild

begin 600 winmail.dat
M>)\^(A8*`0:0"``$```!``$``0>0!@`(Y`0```#H``$(@`<`
M&$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06``P`.T`<&`!,`
M"P`V`!,``0!%`0$@@`,`#@```-`'!@`3``L`-@`3``$`10$!"8`!`"$```!!
M,T)#-$-$03,S-#5$-#$Q.#8T,C`P-C`Y-S@R.$,S0@`"!P$$@`$`.@```%)%
M.B!;0V]O:V5R72!->6QE>"!204E$(&-O;G1R;VQL97)S+"!A;F0@061A<'1E
M8R!O;F5S('1O;P#J$P$-@`0``@(``@`!`Y`&`'`)```R`P`V
M```#``*`""`&``#`1@!2A0``)VH!`!X``X`((`8`
M`,!&`%2%```!!#DN,``+``2`""`&``#`
M1@`&A0,`!8`((`8``,!&``&%
M"P`!@`@@!@``P$8``X4+``:`""`&
M``#`1@`.A0,`!X`((`8``,!&
M`!"%`P`(@`@@!@``P$8`$84#``F`
M""`&``#`1@`8A0```!X`"H`((`8``,``
M``!&`#:%```!`0`>``N`""`&``#`1@``
M```WA0```0$`'@`,@`@@!@``P$8`.(4`
M``$!``(!"1`!6P,``%<#``#^!```3%I&=6!QKR0#``H`
M(R`T-T97@%00$#`??_"H`"I`/D!Q,"@`_S`%`$5C\(50>R$24.
M40,!`@!C:.$*P'-E=#(&``;#$27V,P1&$[V.Q@?#C`U$2(,
M8&,`4#,+"0%D,S864`NF(%5&;@(0`"!U;F$.L&R`>2P@22!W800@1G(=4`,`
M;F<@"X`@>$5X<`20!4`$8AW`8C)U!4!S=`,0`R!N;P`@:F]Y+B`@1H4+@&0$
M('1H92`"((4?L&\+$2!A9&$%,/\%D!^D(&`%0`N`#K`8("``APF`'K(A4D1!
M0SD<,%<*H@J$"H`M)7)/!1!G#PN`!T`%T`>0P6PA0+-)=!=!YQFP.P`?P04E$+*$",/<#8"`P!)!S
M'<`MD1#`(C2W(8$'D2D0;R2Z)+1/`Z`]!A!T'<`K!"MS'
M$":`"($@,"T@<'<#8`ZP.B2Z/B!9-Y)$;P>1`'!Y,D$@1FL@8`?@=VAY'=%C
M70!P)P5`)J`%0$TME2#8-RXQ,H$B$&,XLC`@?F0FH!]0.2`P"#7``<=)W$H$B>0>0(D<0!;'W!&`8(!_P8P"0,*P4$#`@?R[P
M)+1,VP-2/JE,$`5`3_Y+,7-`<4<@(1)'@3X!'?/O'L$`<"2T'O0O)]!+D!>P
M?G`'@`(P'K$H<2`P'7!I7P(@0N4E%2E#)+1]7-``'@!P``$V6T-O
M;VME`$(0`0```#T`
M```\4&EN92Y,3E@N-"XR,2XP,#`V,3/^0$``!``#D`P%OJM]S9OP$#`/$_
M"00``!X`,4`!!@```$%,15A"`P`:0``>`#!``08```!!
M3$580@,`&4```P#]/^0$```#`(`0_P(!1P`!-P```&,]
M55,[83T@.W`]3F]V871E8V@[;#U)3E1%4DY%5%]315)612TP,#`V,3DQ,#4T
M,3E:+3(W,P```@'Y/P$```!1`-RG0,C`0A`:M+D(`"LOX8(!
M`"]//4Y/5D%414-(+T]5/4Y/5D%414-(+D-/+E5++T-./5)%0TE0245.
M5%,O0TX]04Q%6$(`'@#X/P$106QE>"!";V%G+4UU;G)O90``
M```>`#A``08```!!3$580@(!^S\!40#`#T``04```!213H@`!X`'0X!-@``
M`%M#;V]K97)=($UY;&5X(%)!240@8V]N=')O;&QE``@0`0```&4```!53D9/4E153D%414Q9+$E705-254Y.24Y'24Y%
M6%!%4E1-3T1%+$)55%-424Q,3D]*3UE&24Y$4U1(14].0D]!4D1!1$%05$5#
M+$)55$Y/5$E.5$5215-4141)3E1(141!0SDV``(!?P`!00```#Q#
M,40S,T1$-#)&-C=$,C$Q.#5%1#`P-C`P.#1$-S(R-S9!.$%%-4!M86EL:&]S
7="YN;W9A=&5C:"YC;RYU:SX`P"$=
`
end




Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Andreas Simon

Bryan Paxton wrote:

> I've talked to a lot of ex-mandrake users who switched to debian simply for apt,
> and who also said they wouldn't gladly switch back if RPM was hacked up to be
> more robust, flexiable, and reliable as deb(dpkg,apt).

I for myself was once also a happy debian user.
But I changed to Red Hat and later to Mandrake
because of various reasons. Do not use this
as an argument, I know enough people who'd quit
with debian and are know using SuSE or Redhat.

> The first is a waste of time and man power IMHO.

As Debian reinvented the wheel with it's package format
some years ago, it was a waste of resources.
They could have also improved RPM instead. There were no
technical arguments to do otherwise, it was as
allways some political and emotional choise,
wasn't it?

> Debian's package system is right there to be used, why try to re-invent the
> wheel ? It just doesn't make sense to do so.

To reuse your words, it just doesn't make sense
to do otherwise.
 
> But what are the drawbacks ? Are there any at all ?

Yeah, of course, there allways are, aren't there?

Face it, RPM is mainstream, if you like it or not!
What I value is, I can go to any project homepage
and gladly find some rpms but rarly debs.

Software developer could use time better than
having to support different package formats
to distribute their software.

What Linux needs last is many package formats.
One it enough. And when you look at numbers
it's not deb. Of course it could be deb but
as the mojority of distributions and other
software projects goes with rpm it would'nt
be wise to switch to deb, better to improve
rpm.

What does the Linux Standard Project says
about this matter?

Cheers,
~Andreas




Re: [Cooker] Wheel mouse support in 7.1/Cooker

2000-06-19 Thread David BAUDENS

Christopher Gallant écrivit :
 
> You guys can get mouse wheel to work? damn mine doesnt i have the logitech
> with the thumb marble, And i have launced Imwheel too no scroll
   

? What is the name of this mouse (it's write under the mouse).

-- 
MandrakeSofthttp://www.mandrakesoft.com
PARIS, FRANCE   --David




Re: [Cooker] Install from running environment?

2000-06-19 Thread Pixel

[EMAIL PROTECTED] writes:

> Is there a a way to install 7.1 from within a running version of 
> linux if it is already running the same kernel? I don't see any 
> problem with this but I don't know how to do it.

you mean upgrade ???




[Cooker] RPM(s) worst enemy but Mandrake's best friend...

2000-06-19 Thread Bryan Paxton


Before I get started I'm only looking at this from a face value perspective.
The nitty gritty details I'm sure will come out later in this thread if it 
becomes one : )

RPM is reliable, it has proven to be so for the most part. But deb truely has it
beat in more than one way. 

Dependancy handling... For one the package system is not decentralised
which gives it the upperhand on dealing with dependices and the over all
system(DB) of packages. 

The the second, which really attracts most
users is apt, nothing really needs to be said about this other than it can't get
any better than this. Run time dist upgrades is another advantage of apt. It's
plain as day that 'apt-get dist upgrade' is a much better soulution than trying
to figure "do I need this or this or this ?" from an ftp mirror of mandrake.

I've talked to a lot of ex-mandrake users who switched to debian simply for apt,
and who also said they wouldn't gladly switch back if RPM was hacked up to be
more robust, flexiable, and reliable as deb(dpkg,apt). 

There's only one of two solutions here. 
1) Simply get hands dirty by diving into the RPM source code and hack it up
2) Switch to debian package system

The first is a waste of time and man power IMHO.
Debian's package system is right there to be used, why try to re-invent the
wheel ? It just doesn't make sense to do so.

But what are the drawbacks ? Are there any at all ?

Personally I don't see so, but I'm really only touching on this subject at face
value.

I await the flame : )

-- 
Bryan Paxton

"How should I know if it works? That's what beta testers are for. I
  only coded it."
 -- Linus Torvalds.

Public key can be found at http://speedbros.org/Bryan_Paxton.asc




Re: [Cooker] kernel compil

2000-06-19 Thread Francis GALIEGUE

On Sun, 18 Jun 2000, Diablero wrote:

> Why when I recompile my kernel smp, the name of kernel and location of
> modules is not smp ?
> 

Probably because you didn't change the EXTRAVERSION in Makefile :)

You can give the kernel any version number you like, see the tope of the
Makefile.

-- 
Francis Galiegue, [EMAIL PROTECTED]
"Programming is a race between programmers, who try and make more and more
idiot-proof software, and universe, which produces more and more remarkable
idiots. Until now, universe leads the race"  -- R. Cook




Re: [Cooker] U66 solved

2000-06-19 Thread Pixel

"bobby dowling" <[EMAIL PROTECTED]> writes:

> What do you mean the -d flag without the -X flags?
> 
> So, you can say -dX and those WD drives that froze the system before would 
> work?

nope, froze anyway here :(




Re: [Cooker] Wheel mouse support in 7.1/Cooker

2000-06-19 Thread Christopher Gallant

You guys can get mouse wheel to work? damn mine doesnt i have the logitech with
the thumb marble, And i have launced Imwheel too no scroll

> root écrivit :
> 
> [...]
> 
> > 1. it works with Netscape and other Motif applications (Nedit), but the
> > scrolling is worse (i.e. rough, not smooth as before);
> > 2. it still works in most GNOME applications, but the scrolling is worse
> > (idem, add a really annoying 'circular' scrolling);
> > 3. it stopped working, or works partially, in some GTK/GNOME working
> > applications (e.g. gentoo, I can't scroll my shortcuts anymore);
> > 4. it most definitely stopped working with WINGs windows;
> > 5. it most definitely stopped working with aterm;
> > 6. it still doesn't work with KDE applications.
> 
> [...]
> 
> Have you launch Imwheel? Wheel work fines in all applications with it.
> 
> -- 
> MandrakeSofthttp://www.mandrakesoft.com
> PARIS, FRANCE   --David




Re: [Cooker] Wheel mouse support in 7.1/Cooker

2000-06-19 Thread David BAUDENS

root écrivit :

[...]

> 1. it works with Netscape and other Motif applications (Nedit), but the
> scrolling is worse (i.e. rough, not smooth as before);
> 2. it still works in most GNOME applications, but the scrolling is worse
> (idem, add a really annoying 'circular' scrolling);
> 3. it stopped working, or works partially, in some GTK/GNOME working
> applications (e.g. gentoo, I can't scroll my shortcuts anymore);
> 4. it most definitely stopped working with WINGs windows;
> 5. it most definitely stopped working with aterm;
> 6. it still doesn't work with KDE applications.

[...]

Have you launch Imwheel? Wheel work fines in all applications with it.

-- 
MandrakeSofthttp://www.mandrakesoft.com
PARIS, FRANCE   --David




[Cooker] Wheel mouse support in 7.1/Cooker

2000-06-19 Thread root

I've just finished upgrading to LM 7.1 and I'm generally pleased with.
There is one feature, however, that resulted in a mild disappointment:
wheelmouse support.

I have a Logitech wheelmouse (don't remember the exact model name) that
worked perfectly under Linux Mandrake 7.0, that is, it worked great with
GTK/GNOME applications and, after applying a patch (thanks Daniel!),
with Netscape too; it didn't work with KDE applications.

Now, I was eager to try the 7.1 release because the feature list said
"Wheel mouses are now fully functionnal with most applications
(netscape, gnome, KDE, etc.)". What happened:

1. it works with Netscape and other Motif applications (Nedit), but the
scrolling is worse (i.e. rough, not smooth as before);
2. it still works in most GNOME applications, but the scrolling is worse
(idem, add a really annoying 'circular' scrolling);
3. it stopped working, or works partially, in some GTK/GNOME working
applications (e.g. gentoo, I can't scroll my shortcuts anymore);
4. it most definitely stopped working with WINGs windows;
5. it most definitely stopped working with aterm;
6. it still doesn't work with KDE applications.

Now it seems to me that this is a classical "one step forward, two step
backwards" situation, that is, if I haven't messed up something :) (but
this is Mandrake 7.1 right out of the box, so I think it's not the
case).

Question(s): is this being worked upon in the cooker version? is there a
patch or something that can be applied to correct the above situation?

Ciao

-- 
Roberto Rosselli Del Turco  e-mail: [EMAIL PROTECTED]
Dipartimento di Scienze [EMAIL PROTECTED]
del Linguaggio  Then spoke the thunder  DA
Universita' di Torino   Datta: what have we given?  (TSE)
 
  Hige sceal the heardra, heorte the cenre,
  mod sceal the mare,   the ure maegen litlath.  (Maldon 312-3)




Re: [Cooker] SHOW-STOPPER: Cannot export file systems with 7.1

2000-06-19 Thread Ron Stodden

Graham Percival wrote:

> Really?  I've never had problems installing crypto RPMs on my
> masq'ed internal network.  Maybe you configured your NAT / firewall
> incorrectly.

Same problem even with the gateway machine firewall taken down
(except for masquerading).

Error box is:

An error occurred
Net::FTP: Bad peer adddress ...propagated.

The install then loops around repeatedly trying the crypto
download.   I have to hit a lower star to recover.

This occurs on any choice of mirror, and is quite uninformative to me
on what the error was and what needs to be done to fix it.

-- 

Regards,

Ron. [AU] - sent by Mandrake Linux.