[blfs-dev] .. r15999 - in trunk/BOOK: general/sysutils introduction/welcome

Fernando de Oliveira famobr at yahoo.com.br
Tue May 19 16:48:06 PDT 2015


I'm removing [blfs-book] from the subject, because I could never fix my
filters, and and they put in the book's folder.

On 19-05-2015 20:04, Ken Moffat wrote:
> On Tue, May 19, 2015 at 06:19:48PM -0300, Fernando de Oliveira wrote:
>> I am cross-sending to dev, because a discussion may be necessary.
>>
> And I am replying for a second time (this address is not subscribed
> to -book, I keep forgetting that).  So, I'll take this to -dev
> because that is where it actually started, on 7th April.
> 
> For anybody on -dev missing the context, we are discussing unzip.
> 
>> On 19-05-2015 14:07, fernando at higgs.linuxfromscratch.org wrote:
>>> Author: fernando
>>> Date: Tue May 19 10:07:32 2015
>>> New Revision: 15999
>>>
>>> Log:
>>> Revert modification by Douglas: there is a test suite for unzip.
>>
>> I want to ask apologies to Douglas.
>>
>> My script is different from the book, so I have the tests, he doesn't
>>
>>
>> I never noticed somebody modified the instructions.
>>
> Yeah, things change under us all.
> 
> 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
$

> 
> In the commit message, I wrote:
> 
> "unzip: Use the generic target (new in unzip60, apparently) : this
> fixes unzipping to files larger than 2GiB - e.g. raspberry pi images
> - on i686.It also mean we do the same for i686 and x86_64. The
> previous commented option might have also worked, but I guess nobody
> used to have any reason to unzip such large files."
> 
> And in the book, it explains the use of the generic target (and that
> is why you would have associated the change with me):

Yes, new, and apparently accepts configure.

I never thought it was you.

> "This target begins by running a configure script (unlike the older
> targets such as linux and linux_noasm) which creates a flags file
> that is then used in the build. This ensures that the 32-bit x86
> build receives the right flags to unzip files which which are larger
> than 2GB when extracted."
>>
>> Why the change was made? IIRC I even had a not very pleasant incident
>> with git developers, before needing to change the book for that.
>>
> 
> In April, somebody tried to unzip a Pi image on i686, and failed.
> He reported it to -dev :
> http://lists.linuxfromscratch.org/pipermail/blfs-dev/2015-April/030007.html
> 
> When I tried to fix that on i686, I looked at fedora's specfile and
> saw that they had a fix.  But when I tried to use what I _thought_
> they were doing, it failed to compile.  So, I googled, probably for
> the error message that trying to unzip on i686 used to produce, and
> found a different fix at Pardus - it worked for me, so I copied it
> and added an explanation.

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.

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.
> 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 ;-)
> 

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.


> 
> 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.

Apologies to all, and to Douglas, again.

-- 
[]s,
Fernando


More information about the blfs-dev mailing list