Re: [Cooker] Re: 7.1 beta - kdf missing --- AGAIN! - Bad, bad, bad, slapped wrist.

2000-05-25 Thread Ron Stodden

OS wrote:
> 
> All the best developers say with the upmost certainty that there is no bug
> because it cannot be reproduced on their system. Surely it is not correct to
> say that a situation is 'disproved' simply because you cannot reproduce this
> problem on your machine. If this is your code (I don't know if it is or not)
> and your feelings are hurt because someone repeatedly says it doesn't work,
> well tough !

No, kdf is NOT my code and I have no rights in it - other than as a
happy user.

kdf is proved to work correctly on my two bog-standard systems.

Later:  I take that back.  kdf will crash and vanish if there are
mounts done outside kdf on both /dev/loop0 (that alone is OK) and
/dev/loop1.  These mounts outside kdf themselves are OK.  

mount -t iso9660 -o ro,loop=/dev/loop0 hydrogen3-inst.iso
/mnt/cdimage1
mount -t iso9660 -o ro,loop=/dev/loop1 hydrogen3-ext.iso
/mnt/cdimage2

These mount options are NOT documented in man mount.

Unfortunately, these two mounts are what you must do to recover the
installation files from the two beta3 iso 9660 image files (the new
beta distribution format) so that you can install using
/images/hd.img after merging the two images into a third place (which
needs all of 2 GB).

Note that the ownership of all the files in the iso images is set to
root:root, and cannot be altered because the mounts are read-only
(presumably because they are CDROM images).  I have not tried
mounting them rw.

-- 

Regards,

Ron. [AU] - sent by Mandrake Linux.




Re: [Cooker] Re: 7.1 beta - kdf missing --- AGAIN! - Bad, bad, bad, slapped wrist.

2000-05-25 Thread OS

> As I informed you when you made this claim before, neither of these
> situations occurs here.  I am surprised that once disproved you would
> persist with them?

All the best developers say with the upmost certainty that there is no bug
because it cannot be reproduced on their system. Surely it is not correct to
say that a situation is 'disproved' simply because you cannot reproduce this
problem on your machine. If this is your code (I don't know if it is or not)
and your feelings are hurt because someone repeatedly says it doesn't work,
well tough ! All coders, myself included, must set feelings aside when
submitting there code for test. Unfortunately pride does not come into the
equation when someone finds a bug in your code.

Owen

On Thu, 25 May 2000, you wrote:
> Civileme wrote:
> 
> > Unfortunately, kdiskfree seems to be seriously bugged.  I like it and use it in
> > 6.1 but on partitions of 6 G or so I am always shown 1.86G.  Another problem is
> > accurately representing nfs mounts   I am not among those who believe a
> > broken tool is better than no tool at all.  
> 
> As I informed you when you made this claim before, neither of these
> situations occurs here.  I am surprised that once disproved you would
> persist with them?
> 
> > But looking at the latest source tarball from kde.org, I
> > am encountering coding errors in kdf that the compiler will not accept.
> 
> Surely such things are easily corrected at the source level?  Such
> activity by Mandrake is what results in the -mdk versions -
> it is their job.   But thanks for attempting a compile.
> 
> > So, I think they are making the right decision even if their reasons are
> > different.
> 
> I am still awaiting their decision and rationale - so far, nothing.
> 
> Again, although installing kdf-0.5.1-1mdk.i586.rpm from 6.1 produces
> two warnings, I assure you all that it works just fine in all
> respects for me in both 7.0 and 7.1 with > 6GB partitions and nfs
> mounts galore and is in constant use with no problems.  A wonderful
> piece of software!
> 
> -- 
> 
> Regards,
> 
> Ron. [AU] - sent by Mandrake Linux.




Re: [Cooker] Re: 7.1 beta - kdf missing --- AGAIN!

2000-05-25 Thread Ron Stodden

Civileme wrote:

> Unfortunately, kdiskfree seems to be seriously bugged.  I like it and use it in
> 6.1 but on partitions of 6 G or so I am always shown 1.86G.  Another problem is
> accurately representing nfs mounts   I am not among those who believe a
> broken tool is better than no tool at all.  

As I informed you when you made this claim before, neither of these
situations occurs here.  I am surprised that once disproved you would
persist with them?

> But looking at the latest source tarball from kde.org, I
> am encountering coding errors in kdf that the compiler will not accept.

Surely such things are easily corrected at the source level?  Such
activity by Mandrake is what results in the -mdk versions -
it is their job.   But thanks for attempting a compile.

> So, I think they are making the right decision even if their reasons are
> different.

I am still awaiting their decision and rationale - so far, nothing.

Again, although installing kdf-0.5.1-1mdk.i586.rpm from 6.1 produces
two warnings, I assure you all that it works just fine in all
respects for me in both 7.0 and 7.1 with > 6GB partitions and nfs
mounts galore and is in constant use with no problems.  A wonderful
piece of software!

-- 

Regards,

Ron. [AU] - sent by Mandrake Linux.




Re: [Cooker] Re: 7.1 beta - kdf missing --- AGAIN!

2000-05-24 Thread Civileme

On Tue, 23 May 2000, you wrote:
> Here is a repeat of mine of April 28, the first of 6 messages in
> Cooker on this subject.
> 
> There has been no response from MandrakeSoft.
> 
> This really MUST be in beta3!   IMHO, of course .
> 
> Could somebody seriously look into why this package continues to be
> omitted?
> 
> The original RPM packager in the 6.1 release was none other than Gael
> Duval himself!


Unfortunately, kdiskfree seems to be seriously bugged.  I like it and use it in
6.1 but on partitions of 6 G or so I am always shown 1.86G.  Another problem is
accurately representing nfs mounts   I am not among those who believe a
broken tool is better than no tool at all.  And there are alternatives.

for example


   ls -a -l -R -H (filesystem_mount_point) | grep ./ -A 1

Is more fine-grained and was used successfully to detect a netscape usage that
consumed 84Mb in disk caches where kdf was unrevealing  (there were 32
subdirectories of ~ /.netscape/cache, each LESS than the 5Mb limit set).

Yes, it isn't kde, and yes, I am willing to rork on some sort of script/Python
combination for a better graphical tool not necessarily dependent on KDE to
accomplish this task.  But looking at the latest source tarball from kde.org, I
am encountering coding errors in kdf that the compiler will not accept.

So, I think they are making the right decision even if their reasons are
different.

Civileme