Fernando de Oliveira wrote:
Fernando, if you had used 'svn blame | less' you would probably have
spotted that I changed this in r15811.
$ svn blame | less
svn: E205001: Try 'svn help blame' for more information
svn: E205001: Poucos argumentos fornecidos
svn blame ./general/sysutils/unzip.xml
works for me.
I was banned from git, because asked there about an error in the tests,
related to unzip. This was considered a spam. Now, I am in their filter.
Fortunately, one developer sent me a private message with the fix that I
included in the book.
Interesting. However I don't understand the relationship between git and unzip.
Is there a regression test that uses unzip? We don't mention that.
If ou made the change and the git test does not fail, I don't mind, your
commands are better, if everything is OK, and the unzip tests are not
very relevant.
We are working with linux, not *generic*
First, this is a new, improved, target in unzip60 and it does the
right thing. On an i486, using asm in unzip was perhaps a good
idea.
Could not understand.
On a modern machine, where zip files are mostly only used for
obscure sources such as fonts, I see no particular reason why any
possible runtime improvement from using asm would be important.
I agree with that!
Even on x86_64, unzipping that raspbian image takes a long time.
Unfortunately, it appears that many Pi users probably run third-rate
OS's - that is the only reason I can think of for using a zipped
file ;-)
Third rate? Oh, I suppose what is meant is the users' desktop systems. :)
IIRC, what mattered for me was the -DNO_LCHMOD.
Second, it means what we have identical instructions for i686 and
x86_64. I reagard that as a Good Thing.™
Agree, again, if git tests are OK.
I agree too.
But, if the name of the target offends you, feel free to spend time
downloading the Pi image mentioned in the archive and trying to unzip
it on a recent i686 system, and then come up with whatever different
changes you want to make.
Name does not offend me, I was thinking something completely different.
Will not spend only the time to write this line, for that. Perhaps you
could spend some time checking that the new instructions do not brake
git's test? Oh! Even this is not important, thinking better: just have
to add "test fails for known reason", if that proves to be the case.
Again, I do like you, your posts and interventions in the book, please
do not feel offended. Last thing I want is a fight with you.
Douglas, I will revert my modification tomorrow. My ventilator broke,
and i'm under more than 35 Celsius.
That's a little warm. I certainly would not be able to concentrate in that
environment. I'd probably be a bit irritable too.
I might add that instead of just changing something after a recent modification
by another editor, asking on -dev generally clears things up.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
