You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Jeff Levitt <de...@mylevita.com> on 2005/03/31 02:40:49 UTC

[doc] Derby-191 fixes some Linux doc build problems

I opened Jira issue 191:
http://issues.apache.org/jira/browse/DERBY-191 

Jean has already made the change and committed it in
revision 159548.  Those of you working on docs should
'svn up' to get the latest.

The changes create propset values of "native" for the
dita files that had not been set at all.  This should
solve some (but maybe not all) the problems some
people were having creating a build on Linux.  

Re: [doc] Derby-191 fixes some Linux doc build problems

Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Andrew McIntyre wrote:
> On Mar 30, 2005, at 4:40 PM, Jeff Levitt wrote:
> 
>> The changes create propset values of "native" for the
>> dita files that had not been set at all.
>  
> Really? I was pretty sure that I got them all with revision 157620. 
> Perhaps I unknowingly undid this somehow with a later change?

Yeah, don't know how that could have happened.

In derby/docs/trunk/src I did this:

    $ for file in */*.dita */*.ditamap
    > do
    > echo $file >> /tmp/dita-check.txt
    > svn propget svn:eol-style $file >> /tmp/dita-check.txt
    > done

Good entries looked like this:

    adminguide/adminconrefs.dita
    native
    adminguide/cadminadvtops.dita
    native
    adminguide/cadminapps49914.dita
    native
    adminguide/cadminapps59125.dita
    native

Entries missing a setting looked like this:

    adminguide/tadminadv804410.dita
    adminguide/tadminadv804451.dita
    adminguide/tadminapps811302.dita
    adminguide/tadminapps811345.dita
    adminguide/tadminapps811695.dita

> Anyway, Thanks Jeff and Jean for catching it! Personally, I've been 
> having no problems building the docs on Mac OS X or Linux, so I'm 
> curious if this does in fact fix the problems others have been having 
> building the docs.

At the very least it should eliminate the svn:eol-style setting as an issue.

  -jean


Re: [doc] Derby-191 fixes some Linux doc build problems

Posted by Andrew McIntyre <mc...@gmail.com>.
On Mar 30, 2005, at 4:40 PM, Jeff Levitt wrote:

> The changes create propset values of "native" for the
> dita files that had not been set at all.

Really? I was pretty sure that I got them all with revision 157620. 
Perhaps I unknowingly undid this somehow with a later change?

Anyway, Thanks Jeff and Jean for catching it! Personally, I've been 
having no problems building the docs on Mac OS X or Linux, so I'm 
curious if this does in fact fix the problems others have been having 
building the docs.

andrew


Re: [doc] Derby-191 fixes some Linux doc build problems

Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
scott hutinger wrote:
> Possibly 64bit has something to do with no failures.  Working at a 
> university, I get the cheapest of everything :-)

Actually I just posted gentoo (32bit) successful results, too.  :-)

Actually this was my holiday present to myself this year. I was getting 
tired of forrest builds taking 40-60 minutes on my gentoo box.  :-)
This one just so happened to come with fedora core 3 installed.

> At least that is one item to examine beside character encodiBUILD SUCCESSFULng.  Wow, 3 
> x86_64 (I thought I saw an echo!)

It's an AMD Athlon 64 / Opteron processor. I love it.

Now, back to topic.  I'm only looking at that final "BUILD SUCCESSFUL" 
message. Somehow I suspect that BUILD SUCCESSFUL may not mean "built 
correctly" -- that would be a separate issue. I haven't been checking 
the docs themselves.

  -jean

Re: [doc] Derby-191 fixes some Linux doc build problems

Posted by scott hutinger <s-...@wiu.edu>.
Possibly 64bit has something to do with no failures.  Working at a 
university, I get the cheapest of everything :-)
At least that is one item to examine beside character encoding.  Wow, 3 
x86_64 (I thought I saw an echo!)
And yes, thanks for pointing out the src code download.  I am pretty 
certain that will cause more problems than anything.  Possibly my 
machine has some type of cache coherency problem (this is going a bit deep)?

x86info
x86info v1.12b.  Dave Jones 2001-2003
<snip>
Found 1 CPU
--------------------------------------------------------------------------
Family: 15 Model: 2 Stepping: 9 Type: 0 Brand: 10
CPU Model: Pentium 4 (Northwood) [D1] Original OEM
Processor name string: Intel(R) Celeron(R) CPU 2.40GHz

Instruction TLB: 4K, 2MB or 4MB pages, fully associative, 128 entries.
Data TLB: 4KB or 4MB pages, fully associative, 64 entries.
L1 Data cache:
        Size: 8KB       Sectored, 4-way associative.
        line size=64 bytes.
No level 2 cache or no level 3 cache if valid 2nd level cache.
Instruction trace cache:
        Size: 12K uOps  8-way associative.
L2 unified cache:
        Size: 128KB     2-way associative.
        line size=64 bytes.
Number of logical processors supported within the physical package: 0

thanks,
scott


Jean T. Anderson wrote:

> scott hutinger wrote:
>
>> Jean,
>> could you give a
>> uname -a
>> for the machine that did the fedora core 3 build?
>
>
> [jta@gertie3 trunk]$ uname -a
> Linux gertie3.swlogic.net 2.6.10-1.760_FC3 #1 Wed Feb 2 00:12:56 EST 
> 2005 x86_64 x86_64 x86_64 GNU/Linux
>
> This was my first attempt to build so I didn't do anything "special" 
> when following Jeff's instructions at 
> http://incubator.apache.org/derby/manuals/dita.html -- with the 
> exception of one thing.  I initially downloaded the source 
> distribution for the toolkit and that didn't work "out of the box". 
> The binary distribution worked fine.
>
>  -jean
>


Re: [doc] Derby-191 fixes some Linux doc build problems

Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
scott hutinger wrote:
> Jean,
> could you give a
> uname -a
> for the machine that did the fedora core 3 build?

[jta@gertie3 trunk]$ uname -a
Linux gertie3.swlogic.net 2.6.10-1.760_FC3 #1 Wed Feb 2 00:12:56 EST 
2005 x86_64 x86_64 x86_64 GNU/Linux

This was my first attempt to build so I didn't do anything "special" 
when following Jeff's instructions at 
http://incubator.apache.org/derby/manuals/dita.html -- with the 
exception of one thing.  I initially downloaded the source distribution 
for the toolkit and that didn't work "out of the box". The binary 
distribution worked fine.

  -jean

Re: [doc] Derby-191 fixes some Linux doc build problems

Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
scott hutinger wrote:
> Jean,
> could you give a
> uname -a
> for the machine that did the fedora core 3 build?
>

also it worked for me on Gentoo:

jta@gertie-too trunk $ uname -a
Linux gertie-too 2.6.7-gentoo-r11 #3 Thu Aug 12 16:44:12 PDT 2004 i686 
Intel(R) Pentium(R) 4 CPU 2.53GHz GenuineIntel GNU/Linux

  -jean

Re: [doc] Derby-191 fixes some Linux doc build problems

Posted by scott hutinger <s-...@wiu.edu>.
Jean,
could you give a
uname -a
for the machine that did the fedora core 3 build?

thanks,
scott

Jean T. Anderson wrote:

> all docs build successfully (html and pdf) on fedora core 3.
>
>  -jean
>
> Jeff Levitt wrote:
>
>> I opened Jira issue 191:
>> http://issues.apache.org/jira/browse/DERBY-191
>> Jean has already made the change and committed it in
>> revision 159548.  Those of you working on docs should
>> 'svn up' to get the latest.
>>
>> The changes create propset values of "native" for the
>> dita files that had not been set at all.  This should
>> solve some (but maybe not all) the problems some
>> people were having creating a build on Linux.  
>
>


Re: [doc] Derby-191 fixes some Linux doc build problems

Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
all docs build successfully (html and pdf) on fedora core 3.

  -jean

Jeff Levitt wrote:
> I opened Jira issue 191:
> http://issues.apache.org/jira/browse/DERBY-191 
> 
> Jean has already made the change and committed it in
> revision 159548.  Those of you working on docs should
> 'svn up' to get the latest.
> 
> The changes create propset values of "native" for the
> dita files that had not been set at all.  This should
> solve some (but maybe not all) the problems some
> people were having creating a build on Linux.