From dennisveatch at bellsouth.net  Wed Sep  1 23:58:21 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Wed, 1 Sep 2010 17:58:21 -0400
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <AANLkTikHkmpjZp1=HUjvswFpt3QX4XAeuEya2_RfSPxN@mail.gmail.com>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<AANLkTik6HrOTNfOgPkGPwaF=f5=dfdMALuFp2=amFO80@mail.gmail.com>
	<AANLkTikHkmpjZp1=HUjvswFpt3QX4XAeuEya2_RfSPxN@mail.gmail.com>
Message-ID: <201009011758.22701.dennisveatch@bellsouth.net>

On Monday 30 August 2010 3:13:03 pm samuel wrote:
> compile log:
> http://foo-projects.org/~elangelo/docbook-sgml-4.5.bz2
> 
> On Mon, Aug 30, 2010 at 9:10 PM, samuel <samuel.verstraete at gmail.com> wrote:
> > this ain't working for me... docbook-sgml is still failing on my brand
> > new x86-64 1.6.5 install. fix it!
> > 
> > On Tue, Aug 24, 2010 at 11:50 PM, Zbigniew Luszpinski <zbiggy at o2.pl> 
wrote:
> >>> zbiggy,
> >>> 
> >>> I give you full marks for daring to open the docbook can of worms, but
> >>> something is still not quite right, because the update and the fix you
> >>> proposed above don't work for me after a fresh install of the official
> >>> 1.6.5-x86_64 ISO.
> >>> 
> >>> Full details available at:
> >>> http://bugs.lunar-linux.org/view.php?id=432
> >> 
> >> I have just downloaded 32bit 1.6.5 iso.
> >> When lunar fix of *.la files finishes I will install it and try to lin
> >> jade.
> >> 
> >> docbooks are arch independent so this bug should be reproducible.
> >> Will let you know my findings.
> >> 
> >> have a nice day,
> >> Zbigniew Luszpinski
> >> 

On an existing install;
  inflating: /usr/src/sgml/4.5/docbookx.dtd  
  inflating: /usr/src/sgml/4.5/htmltblx.mod  
  inflating: /usr/src/sgml/4.5/README  
  inflating: /usr/src/sgml/4.5/soextblx.dtd  
ls: cannot access /usr/share/sgml/docbook/3*: No such file or directory
ls: cannot access /usr/share/sgml/docbook/4*: No such file or directory
ls: cannot access /usr/share/sgml/docbook/docbook-sgml*: No such file or 
directory
install-catalog: removal of /usr/share/sgml/docbook/sgml/catalog from 
/etc/sgml/catalog
Warning: /usr/share/sgml/docbook/sgml/catalog was not found in the centralized 
catalog /etc/sgml/catalog
+ building "docbook-sgml" version "4.5" in /usr/src/sgml
+ CC_EXT="ccache "
+ CXX_EXT="ccache "
+ CC="gcc"
+ CXX="g++"
+ CPP="cpp"
+ CFLAGS=" -O2 -march=x86-64 -pipe"
+ CXXFLAGS=" -O2 -march=x86-64 -pipe"
+ CPPFLAGS=""
+ LDFLAGS=" -s"
+ MAKES="4"
+ Enabled wrapper script usage
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.3/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.2/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.1/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.5/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/3.1/catalog: 
No such file or directory
Creating /var/log/lunar/compile/docbook-sgml-4.5.bz2 


-- 
Dennis Veatch

From samuel.verstraete at gmail.com  Thu Sep  2 07:35:18 2010
From: samuel.verstraete at gmail.com (Samuel.verstraete@gmail.com)
Date: Thu, 02 Sep 2010 07:35:18 +0200
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <201009011758.22701.dennisveatch@bellsouth.net>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<AANLkTik6HrOTNfOgPkGPwaF=f5=dfdMALuFp2=amFO80@mail.gmail.com>
	<AANLkTikHkmpjZp1=HUjvswFpt3QX4XAeuEya2_RfSPxN@mail.gmail.com>
	<201009011758.22701.dennisveatch@bellsouth.net>
Message-ID: <1283405718.28269.5.camel@Nokia-N900-51-1>

I propose to revert this commit... It's clearly not well tested. Even by just looking at the code I can see multiple problems.

----- Original message -----
> On Monday 30 August 2010 3:13:03 pm samuel wrote:
> > compile log:
> > http://foo-projects.org/~elangelo/docbook-sgml-4.5.bz2
> > 
> > On Mon, Aug 30, 2010 at 9:10 PM, samuel <samuel.verstraete at gmail.com>
> > wrote:
> > > this ain't working for me... docbook-sgml is still failing on my
> > > brand new x86-64 1.6.5 install. fix it!
> > > 
> > > On Tue, Aug 24, 2010 at 11:50 PM, Zbigniew Luszpinski <zbiggy at o2.pl> 
> wrote:
> > > > > zbiggy,
> > > > > 
> > > > > I give you full marks for daring to open the docbook can of
> > > > > worms, but something is still not quite right, because the
> > > > > update and the fix you proposed above don't work for me after a
> > > > > fresh install of the official 1.6.5-x86_64 ISO.
> > > > > 
> > > > > Full details available at:
> > > > > http://bugs.lunar-linux.org/view.php?id=432
> > > > 
> > > > I have just downloaded 32bit 1.6.5 iso.
> > > > When lunar fix of *.la files finishes I will install it and try to
> > > > lin jade.
> > > > 
> > > > docbooks are arch independent so this bug should be reproducible.
> > > > Will let you know my findings.
> > > > 
> > > > have a nice day,
> > > > Zbigniew Luszpinski
> > > > 
> 
> On an existing install;
>? ?  inflating: /usr/src/sgml/4.5/docbookx.dtd?  
>? ?  inflating: /usr/src/sgml/4.5/htmltblx.mod?  
>? ?  inflating: /usr/src/sgml/4.5/README?  
>? ?  inflating: /usr/src/sgml/4.5/soextblx.dtd?  
> ls: cannot access /usr/share/sgml/docbook/3*: No such file or directory
> ls: cannot access /usr/share/sgml/docbook/4*: No such file or directory
> ls: cannot access /usr/share/sgml/docbook/docbook-sgml*: No such file or 
> directory
> install-catalog: removal of /usr/share/sgml/docbook/sgml/catalog from 
> /etc/sgml/catalog
> Warning: /usr/share/sgml/docbook/sgml/catalog was not found in the
> centralized?  catalog /etc/sgml/catalog
> + building "docbook-sgml" version "4.5" in /usr/src/sgml
> + CC_EXT="ccache "
> + CXX_EXT="ccache "
> + CC="gcc"
> + CXX="g++"
> + CPP="cpp"
> + CFLAGS=" -O2 -march=x86-64 -pipe"
> + CXXFLAGS=" -O2 -march=x86-64 -pipe"
> + CPPFLAGS=""
> + LDFLAGS=" -s"
> + MAKES="4"
> + Enabled wrapper script usage
> cp: failed to preserve ownership for
> /usr/share/sgml/docbook/sgml/4.3/catalog:?  No such file or directory
> cp: failed to preserve ownership for
> /usr/share/sgml/docbook/sgml/4.2/catalog:?  No such file or directory
> cp: failed to preserve ownership for
> /usr/share/sgml/docbook/sgml/4.1/catalog:?  No such file or directory
> cp: failed to preserve ownership for
> /usr/share/sgml/docbook/sgml/4.5/catalog:?  No such file or directory
> cp: failed to preserve ownership for
> /usr/share/sgml/docbook/sgml/3.1/catalog:?  No such file or directory
> Creating /var/log/lunar/compile/docbook-sgml-4.5.bz2 
> 
> 
> -- 
> Dennis Veatch
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100902/9a9669b5/attachment.html>

From samuel.verstraete at gmail.com  Sat Sep  4 15:23:24 2010
From: samuel.verstraete at gmail.com (samuel)
Date: Sat, 4 Sep 2010 15:23:24 +0200
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <201009041520.41083.zbiggy@o2.pl>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<201009011758.22701.dennisveatch@bellsouth.net>
	<1283405718.28269.5.camel@Nokia-N900-51-1>
	<201009041520.41083.zbiggy@o2.pl>
Message-ID: <AANLkTi=q3rpFwhz5C-6fzAN18d4QJ00Pj+J-FjS1OaDy@mail.gmail.com>

On Sat, Sep 4, 2010 at 3:20 PM, Zbigniew Luszpinski <zbiggy at o2.pl> wrote:
>> I propose to revert this commit... It's clearly not well tested. Even
>> by just looking at the code I can see multiple problems.
>
> I will download and install 64bit iso tonight to see the error.
> This is weird that 64bit iso fails because sgml is platform independent.
> Previous sgml/xml modules were really bad. I doubt you would like to go
> back.

at least they installed

>
> have a nice day,
> Zbigniew Luszpinski
>

From zbiggy at o2.pl  Sat Sep  4 15:20:35 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sat, 4 Sep 2010 15:20:35 +0200
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <1283405718.28269.5.camel@Nokia-N900-51-1>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<201009011758.22701.dennisveatch@bellsouth.net>
	<1283405718.28269.5.camel@Nokia-N900-51-1>
Message-ID: <201009041520.41083.zbiggy@o2.pl>

> I propose to revert this commit... It's clearly not well tested. Even
> by just looking at the code I can see multiple problems.

I will download and install 64bit iso tonight to see the error.
This is weird that 64bit iso fails because sgml is platform independent.
Previous sgml/xml modules were really bad. I doubt you would like to go 
back.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100904/42618f7b/attachment.bin>

From dennisveatch at bellsouth.net  Sat Sep  4 15:50:56 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Sat, 4 Sep 2010 09:50:56 -0400
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <AANLkTi=q3rpFwhz5C-6fzAN18d4QJ00Pj+J-FjS1OaDy@mail.gmail.com>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<201009041520.41083.zbiggy@o2.pl>
	<AANLkTi=q3rpFwhz5C-6fzAN18d4QJ00Pj+J-FjS1OaDy@mail.gmail.com>
Message-ID: <201009040950.56560.dennisveatch@bellsouth.net>

On Saturday 04 September 2010 9:23:24 am samuel wrote:
> On Sat, Sep 4, 2010 at 3:20 PM, Zbigniew Luszpinski <zbiggy at o2.pl> wrote:
> >> I propose to revert this commit... It's clearly not well tested. Even
> >> by just looking at the code I can see multiple problems.
> > 
> > I will download and install 64bit iso tonight to see the error.
> > This is weird that 64bit iso fails because sgml is platform independent.
> > Previous sgml/xml modules were really bad. I doubt you would like to go
> > back.
> 
> at least they installed
> 
> > have a nice day,
> > Zbigniew Luszpinski
> 

  inflating: /usr/src/sgml/4.3/dbpoolx.mod  
  inflating: /usr/src/sgml/4.3/docbook.cat  
  inflating: /usr/src/sgml/4.3/docbook.dcl  
  inflating: /usr/src/sgml/4.3/docbook.dtd  
  inflating: /usr/src/sgml/4.3/docbookx.dtd  
  inflating: /usr/src/sgml/4.3/soextblx.dtd  
  inflating: /usr/src/sgml/4.3/ChangeLog  
  inflating: /usr/src/sgml/4.3/htmltblx.mod  
Archive:  /var/spool/lunar/docbook-4.5.zip
  inflating: /usr/src/sgml/4.5/calstblx.dtd  
  inflating: /usr/src/sgml/4.5/catalog.xml  
  inflating: /usr/src/sgml/4.5/dbcentx.mod  
  inflating: /usr/src/sgml/4.5/dbgenent.mod  
  inflating: /usr/src/sgml/4.5/dbhierx.mod  
  inflating: /usr/src/sgml/4.5/dbnotnx.mod  
  inflating: /usr/src/sgml/4.5/dbpoolx.mod  
  inflating: /usr/src/sgml/4.5/docbook.cat  
  inflating: /usr/src/sgml/4.5/docbook.dcl  
  inflating: /usr/src/sgml/4.5/docbook.dtd  
  inflating: /usr/src/sgml/4.5/docbookx.dtd  
  inflating: /usr/src/sgml/4.5/htmltblx.mod  
  inflating: /usr/src/sgml/4.5/README  
  inflating: /usr/src/sgml/4.5/soextblx.dtd  
+ building "docbook-sgml" version "4.5" in /usr/src/sgml
+ CC_EXT="ccache "
+ CXX_EXT="ccache "
+ CC="gcc"
+ CXX="g++"
+ CPP="cpp"
+ CFLAGS=" -O2 -march=x86-64 -pipe"
+ CXXFLAGS=" -O2 -march=x86-64 -pipe"
+ CPPFLAGS=""
+ LDFLAGS=" -s"
+ MAKES="4"
+ Enabled wrapper script usage
Preparing to install docbook-sgml
+ calling "lrm --upgrade docbook-sgml"
+ updating lunar state files after module removal
Removed module: docbook-sgml
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.3/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.2/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.1/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.5/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/3.1/catalog: 
No such file or directory
Creating /var/log/lunar/compile/docbook-sgml-4.5.bz2 
! Problem detected during BUILD

root at MediaServer ~ # ls -al /usr/share/sgml/docbook/sgml/4.3/catalog 
lrwxrwxrwx 1 root root 11 Sep  4 09:49 
/usr/share/sgml/docbook/sgml/4.3/catalog -> docbook.cat
root at MediaServer ~ # ls -al /usr/share/sgml/docbook/sgml/           
total 28
drwxr-xr-x 7 root root 4096 Sep  4 09:49 .
drwxr-xr-x 5 root root 4096 Sep  4 09:49 ..
drwxr-xr-x 2 root root 4096 Sep  4 09:49 3.1
drwxr-xr-x 2 root root 4096 Sep  4 09:49 4.1
drwxr-xr-x 2 root root 4096 Sep  4 09:49 4.2
drwxr-xr-x 2 root root 4096 Sep  4 09:49 4.3
drwxr-xr-x 2 root root 4096 Sep  4 09:49 4.5

root at MediaServer ~ # ls -al /usr/share/sgml/docbook/sgml/4.3
total 392
drwxr-xr-x 2 root root   4096 Sep  4 09:49 .
drwxr-xr-x 7 root root   4096 Sep  4 09:49 ..
-rw-r--r-- 1 root root   8642 Mar 31  2004 calstblx.dtd
lrwxrwxrwx 1 root root     11 Sep  4 09:49 catalog -> docbook.cat
-rw-r--r-- 1 root root   4535 Mar 31  2004 catalog.xml
-rw-r--r-- 1 root root   5446 Mar 31  2004 ChangeLog
-rw-r--r-- 1 root root  10179 Mar 31  2004 dbcentx.mod
-rw-r--r-- 1 root root   1565 Mar 31  2004 dbgenent.mod
-rw-r--r-- 1 root root  59665 Mar 31  2004 dbhierx.mod
-rw-r--r-- 1 root root   4526 Mar 31  2004 dbnotnx.mod
-rw-r--r-- 1 root root 225442 Mar 31  2004 dbpoolx.mod
-rw-r--r-- 1 root root   3832 Mar 31  2004 docbook.cat
-rw-r--r-- 1 root root   2511 Mar 31  2004 docbook.dcl
-rw-r--r-- 1 root root   2772 Mar 31  2004 docbook.dtd
-rw-r--r-- 1 root root   5703 Mar 31  2004 docbookx.dtd
-rw-r--r-- 1 root root   7514 Mar 31  2004 htmltblx.mod
-rw-r--r-- 1 root root    235 Mar 31  2004 README
-rw-r--r-- 1 root root  12819 Mar 31  2004 soextblx.dtd

root at MediaServer ~ # locate docbook.cat
/usr/share/sgml/docbook/sgml/3.1/docbook.cat
/usr/share/sgml/docbook/sgml/4.1/docbook.cat
/usr/share/sgml/docbook/sgml/4.2/docbook.cat
/usr/share/sgml/docbook/sgml/4.3/docbook.cat
/usr/share/sgml/docbook/sgml/4.5/docbook.cat
/usr/share/sgml/docbook/xml/4.1.2/docbook.cat
/usr/share/sgml/docbook/xml/4.2/docbook.cat
/usr/share/sgml/docbook/xml/4.3/docbook.cat
/usr/share/sgml/docbook/xml/4.4/docbook.cat
/usr/share/sgml/docbook/xml/4.5/docbook.cat

-- 
Dennis Veatch

From zbiggy at o2.pl  Sat Sep  4 15:51:21 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sat, 4 Sep 2010 15:51:21 +0200
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <AANLkTi=q3rpFwhz5C-6fzAN18d4QJ00Pj+J-FjS1OaDy@mail.gmail.com>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<201009041520.41083.zbiggy@o2.pl>
	<AANLkTi=q3rpFwhz5C-6fzAN18d4QJ00Pj+J-FjS1OaDy@mail.gmail.com>
Message-ID: <201009041551.29670.zbiggy@o2.pl>

> On Sat, Sep 4, 2010 at 3:20 PM, Zbigniew Luszpinski <zbiggy at o2.pl> 
wrote:
> >> I propose to revert this commit... It's clearly not well tested.
> >> Even by just looking at the code I can see multiple problems.
> > 
> > I will download and install 64bit iso tonight to see the error.
> > This is weird that 64bit iso fails because sgml is platform
> > independent. Previous sgml/xml modules were really bad. I doubt you
> > would like to go back.
> 
> at least they installed

docbook-sgml (and xml) module needs some more tuning. For example the 
removal of previous sgml/xml directory should be if-ed to not remove 
something what does not exist anymore and similar. I have plan to improve 
them but not now. I have just installed 1.6.5 32bit and started to fix 
lunar rebuild compilation bugs.

My work on sgml/xml was not planned. Someday I ended up with broken 
xextproto module because of bad xml. So started to fix what installs xml 
and sgml because they are similar. xextproto uses different docbooks for 
xml validation so this is good probe for correct xml docbook install.
Meanwhile someone overcame this by putting OPTS+=" --without-xmlto" into 
BUILD of xextproto. If you remove this workaround you can use xextproto 
again as verification of correct xml installation.

As far as xml/sgml does not return build error or other red lunar messages 
and apps using xml/sgml docbooks continue to compile well I consider those 
"fixed" for now.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100904/efe052b1/attachment-0001.bin>

From zbiggy at o2.pl  Sat Sep  4 15:56:24 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sat, 4 Sep 2010 15:56:24 +0200
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <201009040950.56560.dennisveatch@bellsouth.net>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<AANLkTi=q3rpFwhz5C-6fzAN18d4QJ00Pj+J-FjS1OaDy@mail.gmail.com>
	<201009040950.56560.dennisveatch@bellsouth.net>
Message-ID: <201009041556.24868.zbiggy@o2.pl>

Dennis,

I commited some changes to docbook-sgml 30 minutes ago. Try them.

have a nice day,
Zbigniew Luszpinski

From dennisveatch at bellsouth.net  Sat Sep  4 16:00:14 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Sat, 4 Sep 2010 10:00:14 -0400
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <201009041556.24868.zbiggy@o2.pl>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<201009040950.56560.dennisveatch@bellsouth.net>
	<201009041556.24868.zbiggy@o2.pl>
Message-ID: <201009041000.14826.dennisveatch@bellsouth.net>

On Saturday 04 September 2010 9:56:24 am Zbigniew Luszpinski wrote:
> Dennis,
> 
> I commited some changes to docbook-sgml 30 minutes ago. Try them.
> 

I did.

> have a nice day,
> Zbigniew Luszpinski


-- 
Dennis Veatch

From samuel.verstraete at gmail.com  Sat Sep  4 16:14:34 2010
From: samuel.verstraete at gmail.com (samuel)
Date: Sat, 4 Sep 2010 16:14:34 +0200
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <201009041551.29670.zbiggy@o2.pl>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<201009041520.41083.zbiggy@o2.pl>
	<AANLkTi=q3rpFwhz5C-6fzAN18d4QJ00Pj+J-FjS1OaDy@mail.gmail.com>
	<201009041551.29670.zbiggy@o2.pl>
Message-ID: <AANLkTinmYTO_2Z_SAtKZiYAskx3HeiCDKTDSJwZqnpCx@mail.gmail.com>

On Sat, Sep 4, 2010 at 3:51 PM, Zbigniew Luszpinski <zbiggy at o2.pl> wrote:
>> On Sat, Sep 4, 2010 at 3:20 PM, Zbigniew Luszpinski <zbiggy at o2.pl>
> wrote:
>> >> I propose to revert this commit... It's clearly not well tested.
>> >> Even by just looking at the code I can see multiple problems.
>> >
>> > I will download and install 64bit iso tonight to see the error.
>> > This is weird that 64bit iso fails because sgml is platform
>> > independent. Previous sgml/xml modules were really bad. I doubt you
>> > would like to go back.
>>
>> at least they installed
>
> docbook-sgml (and xml) module needs some more tuning. For example the
> removal of previous sgml/xml directory should be if-ed to not remove
> something what does not exist anymore and similar. I have plan to improve
> them but not now. I have just installed 1.6.5 32bit and started to fix
> lunar rebuild compilation bugs.
>
> My work on sgml/xml was not planned. Someday I ended up with broken
> xextproto module because of bad xml. So started to fix what installs xml
> and sgml because they are similar. xextproto uses different docbooks for
> xml validation so this is good probe for correct xml docbook install.
> Meanwhile someone overcame this by putting OPTS+=" --without-xmlto" into
> BUILD of xextproto. If you remove this workaround you can use xextproto
> again as verification of correct xml installation.
>
> As far as xml/sgml does not return build error or other red lunar messages
> and apps using xml/sgml docbooks continue to compile well I consider those
> "fixed" for now.

Well that is *F* bullshit... Or you revert what you f* up, or you fix
the can of worms you opened yourself. *I* want to install docbook on
my *NEW* installation and if you don't revert or fix this mess, i'm
gonna do it


>
> have a nice day,
> Zbigniew Luszpinski
>
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar-dev
>

From dennisveatch at bellsouth.net  Sat Sep  4 16:18:08 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Sat, 4 Sep 2010 10:18:08 -0400
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <201009041520.41083.zbiggy@o2.pl>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<1283405718.28269.5.camel@Nokia-N900-51-1>
	<201009041520.41083.zbiggy@o2.pl>
Message-ID: <201009041018.08574.dennisveatch@bellsouth.net>

On Saturday 04 September 2010 9:20:35 am Zbigniew Luszpinski wrote:
> > I propose to revert this commit... It's clearly not well tested. Even
> > by just looking at the code I can see multiple problems.
> 
> I will download and install 64bit iso tonight to see the error.
> This is weird that 64bit iso fails because sgml is platform independent.
> Previous sgml/xml modules were really bad. I doubt you would like to go
> back.
> 
> have a nice day,
> Zbigniew Luszpinski

It is not x86_64 related, disabling PSAFE is sufficient to see that.

SGML_SEARCH_PATH=../..:../../doc:.. \
        jade -t sgml -i html -d ../../docbook-utils.dsl\#html \
                -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml
jade:/usr/share/sgml/docbook/sgml/3.1/dbcent.mod:54:0:E: cannot find "iso-
amsa.gml"; tried "/usr/share/sgml/docbook/sgml/3.1/iso-amsa.gml", "../../iso-
amsa.gml", "../../doc/iso-amsa.gml", "../iso-amsa.gml"
jade:/usr/share/sgml/docbook/sgml/3.1/dbcent.mod:61:0:E: cannot find "iso-
amsb.gml"; tried "/usr/share/sgml/docbook/sgml/3.1/iso-amsb.gml", "../../iso-
amsb.gml", "../../doc/iso-amsb.gml", "../iso-amsb.gml"
jade:/usr/share/sgml/docbook/sgml/3.1/dbcent.mod:68:0:E: cannot find "iso-
amsc.gml"; tried "/usr/share/sgml/docbook/sgml/3.1/iso-amsc.gml", "../../iso-
amsc.gml", "../../doc/iso-amsc.gml", "../iso-amsc.gml"
jade:/usr/share/sgml/docbook/sgml/3.1/dbcent.mod:75:0:E: cannot find "iso-
amsn.gml"; tried "/usr/share/sgml/docbook/sgml/3.1/iso-amsn.gml", "../../iso-
amsn.gml", "../../doc/iso-amsn.gml", "../iso-amsn.gml"
jade:/usr/share/sgml/docbook/sgml/3.1/dbcent.mod:82:0:E: cannot find "iso-
amso.gml"; tried "/usr/share/sgml/docbook/sgml/3.1/iso-amso.gml", "../../iso-
amso.gml", "../../doc/iso-amso.gml", "../iso-amso.gml"
jade:/usr/share/sgml/docbook/sgml/3.1/dbcent.mod:89:0:E: cannot find "iso-
amsr.gml"; tried "/usr/share/sgml/docbook/sgml/3.1/iso-amsr.gml", "../../iso-
amsr.gml", "../../doc/iso-amsr.gml", "../iso-amsr.gml"

-- 
Dennis Veatch

From dennisveatch at bellsouth.net  Sat Sep  4 16:22:00 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Sat, 4 Sep 2010 10:22:00 -0400
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <201009041556.24868.zbiggy@o2.pl>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<201009040950.56560.dennisveatch@bellsouth.net>
	<201009041556.24868.zbiggy@o2.pl>
Message-ID: <201009041022.00468.dennisveatch@bellsouth.net>

On Saturday 04 September 2010 9:56:24 am Zbigniew Luszpinski wrote:
> Dennis,
> 
> I commited some changes to docbook-sgml 30 minutes ago. Try them.
> 
> have a nice day,
> Zbigniew Luszpinski
> _______________________________________________

When I `lin docbook-profile`  this is how docbook-sgml finishes;

+ Enabled wrapper script usage
Creating /var/log/lunar/compile/docbook-sgml-4.5.bz2 
Creating /var/log/lunar/install/docbook-sgml-4.5
Creating /var/log/lunar/md5sum/docbook-sgml-4.5
Creating /var/cache/lunar/docbook-sgml-4.5-x86_64-pc-linux-gnu.tar.bz2
+ updating lunar state files after module installation
+ module size is 1820KB
install-catalog: addition of /usr/share/sgml/docbook/sgml/3.1/catalog in 
/etc/sgml/catalog
Warning: /usr/share/sgml/docbook/sgml/3.1/catalog is already installed in the 
centralized catalog /etc/sgml/catalog
install-catalog: addition of /etc/sgml/catalog in /etc/sgml/catalog
install-catalog: addition of /usr/share/sgml/docbook/sgml/4.1/catalog in 
/etc/sgml/catalog
Warning: /usr/share/sgml/docbook/sgml/4.1/catalog is already installed in the 
centralized catalog /etc/sgml/catalog
install-catalog: addition of /usr/share/sgml/docbook/sgml/4.2/catalog in 
/etc/sgml/catalog
Warning: /usr/share/sgml/docbook/sgml/4.2/catalog is already installed in the 
centralized catalog /etc/sgml/catalog
install-catalog: addition of /usr/share/sgml/docbook/sgml/4.3/catalog in 
/etc/sgml/catalog
Warning: /usr/share/sgml/docbook/sgml/4.3/catalog is already installed in the 
centralized catalog /etc/sgml/catalog
install-catalog: addition of /usr/share/sgml/docbook/sgml/4.5/catalog in 
/etc/sgml/catalog
Warning: /usr/share/sgml/docbook/sgml/4.5/catalog is already installed in the 
centralized catalog /etc/sgml/catalog
install-catalog: removal of /etc/sgml/catalog from /etc/sgml/catalog

When I `lin docbook-sgml` this is how it finishes;
+ LDFLAGS=" -s"
+ MAKES="4"
+ Enabled wrapper script usage
Preparing to install docbook-sgml
+ calling "lrm --upgrade docbook-sgml"
+ updating lunar state files after module removal
Removed module: docbook-sgml
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.3/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.2/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.1/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/4.5/catalog: 
No such file or directory
cp: failed to preserve ownership for /usr/share/sgml/docbook/sgml/3.1/catalog: 
No such file or directory
Creating /var/log/lunar/compile/docbook-sgml-4.5.bz2 
! Problem detected during BUILD




-- 
Dennis Veatch

From zbiggy at o2.pl  Mon Sep  6 03:18:01 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Mon, 6 Sep 2010 03:18:01 +0200
Subject: [Lunar-commits] <moonbase> docbook: major fix, rebuild, ...
In-Reply-To: <201009041018.08574.dennisveatch@bellsouth.net>
References: <20100814205851.393F69B21B@doppio.foo-projects.org>
	<201009041520.41083.zbiggy@o2.pl>
	<201009041018.08574.dennisveatch@bellsouth.net>
Message-ID: <201009060318.08723.zbiggy@o2.pl>

> On Saturday 04 September 2010 9:20:35 am Zbigniew Luszpinski wrote:
> > > I propose to revert this commit... It's clearly not well tested.
> > > Even by just looking at the code I can see multiple problems.
> > 
> > I will download and install 64bit iso tonight to see the error.
> > This is weird that 64bit iso fails because sgml is platform
> > independent. Previous sgml/xml modules were really bad. I doubt you
> > would like to go back.
> > 
> > have a nice day,
> > Zbigniew Luszpinski
> 
> It is not x86_64 related, disabling PSAFE is sufficient to see that.

Ok. I installed new clean 1.6.5 64bit Lunar and reproduced the bug.
Fixed and commited now. For testing purposes I lined docbook-profile.
Whole compiled ok (I skipped optional emacs dependency and python 
bindings).

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100906/d008dc8a/attachment.bin>

From zbiggy at o2.pl  Mon Sep  6 03:30:28 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Mon, 6 Sep 2010 03:30:28 +0200
Subject: Lunar Linux 1.6.5 ISO: 2 things needs some fine tuning
In-Reply-To: <1283144154.21965.7.camel@localhost>
References: <201008292314.37215.zbiggy@o2.pl>
	<1283144154.21965.7.camel@localhost>
Message-ID: <201009060330.37475.zbiggy@o2.pl>

> On Sun, 2010-08-29 at 23:14 +0200, Zbigniew Luszpinski wrote:
> > Hello,
> > 
> > I have just installed Lunar Linux 1.6.5 ISO 32bit.
> > Here are some things which would be nice to improve:
> > 
> > Lunar Linux installer: "Select Time Zone" menu (last screen of Lunar
> > installer): someone forgot to add whole continent: the Europe.
> > The previous Lunar installers have Europe and European countries in
> > time zone menu so this is regression bug.
> 
> Please check this again, I see Europe on both i686 and x86_64 ISOs.
> That one would not slip through my testing, I do live in Europe myself
> ;)

The "Select a timezone" bug is somehow connected to "Select global 
language" menu choice. If I choose en_US in "Select global language" menu 
Europe will be present in "Select a timezone" menu.
But if I choose Polish language (pl_PL.utf8, pl_PL.iso88592, polish) in 
"Select global language" menu then in "Select a timezone" menu there will 
be no Europe but all Continents starting with A letter: Arctica, America, 
Asia, Australia. This bug is present in both 32/64bit isos. Reproducible 
always.

> > Default kernel configuration: it is good to add VMware network
> > driver: VMX net 3. Some people try Linux first as virtual guest.
> > Often use VMware. This network driver can be activated by enabling:
> > CONFIG_VMXNET3 at .config file of kernel.
> 
> Noted. This is however something that you should have told me already
> during beta and rc releases. I expect our developers to actually
> test our releases before we go final.

Thanks. Sorry no time.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100906/fd2ef1c1/attachment.bin>

From dennisveatch at bellsouth.net  Mon Sep  6 12:58:03 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Mon, 6 Sep 2010 06:58:03 -0400
Subject: [Lunar-commits] <moonbase> docbook-sgml,
	xml: fixed build on 64bit Lunars I installed 64bit Lunar (1.6.5 64bit
	iso) and reproduced reported issues on 64bit Lunars. Whole
	docbook-profile module compiled after clean install of iso. The
	compilation went fine. No build errors.
In-Reply-To: <20100906005936.6207B9B223@doppio.foo-projects.org>
References: <20100906005936.6207B9B223@doppio.foo-projects.org>
Message-ID: <201009060658.03385.dennisveatch@bellsouth.net>

On Sunday 05 September 2010 8:53:02 pm Zbigniew Luszpinski wrote:
> commit 60bcd3f117dac1fcc0a03f1dbb328ce1522468fb
> Author: Zbigniew Luszpinski <zbiggy at lunar-linux.org>
> Date:   Mon Sep 6 02:53:02 2010 +0200
> 
>     docbook-sgml,xml: fixed build on 64bit Lunars
>     I installed 64bit Lunar (1.6.5 64bit iso) and reproduced reported
> issues on 64bit Lunars. Whole docbook-profile module compiled after clean
> install of iso. The compilation went fine. No build errors.
> ---

There are still some issues here with docbook-sgml. Though it does now compile 
fine these need tending;

  inflating: /usr/src/sgml/4.5/soextblx.dtd  
ls: cannot access /usr/share/sgml/docbook/3*: No such file or directory
ls: cannot access /usr/share/sgml/docbook/4*: No such file or directory
ls: cannot access /usr/share/sgml/docbook/docbook-sgml*: No such file or 
directory
install-catalog: removal of /usr/share/sgml/docbook/sgml/catalog from 
/etc/sgml/catalog
Warning: /usr/share/sgml/docbook/sgml/catalog was not found in the centralized 
catalog /etc/sgml/catalog
+ building "docbook-sgml" version "4.5" in /usr/src/sgml


And docbook-utils still fails with the same errors as before.



-- 
Dennis Veatch

From zbiggy at o2.pl  Wed Sep  8 01:49:26 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Wed, 8 Sep 2010 01:49:26 +0200
Subject: [Lunar-commits] <moonbase> docbook-sgml,
	xml: fixed build on 64bit Lunars I installed 64bit Lunar (1.6.5 64bit
	iso) and reproduced reported issues on 64bit Lunars. Whole
	docbook-profile module compiled after clean install of iso. The
	compilation went fine. No build errors.
In-Reply-To: <201009060658.03385.dennisveatch@bellsouth.net>
References: <20100906005936.6207B9B223@doppio.foo-projects.org>
	<201009060658.03385.dennisveatch@bellsouth.net>
Message-ID: <201009080149.27346.zbiggy@o2.pl>

> There are still some issues here with docbook-sgml. Though it does now
> compile fine these need tending;
> 
> ls: cannot access /usr/share/sgml/docbook/3*: No such file or directory
> ls: cannot access /usr/share/sgml/docbook/4*: No such file or directory
> ls: cannot access /usr/share/sgml/docbook/docbook-sgml*: No such file
> or directory

These are used to find and remove old sgml dirs (those created before my 
sgml/xml patch entered moonbase). These are totally safe and harmless.
If ls will not find old dirs like you see here they will be not removed 
because they do not exist.

If you or someone else have these dirs send me the full dir names - I will 
replace * with full name and add if to remove it only when exist.
You can add this if or -d test ladder yourself.

> install-catalog: removal of /usr/share/sgml/docbook/sgml/catalog from
> /etc/sgml/catalog
> Warning: /usr/share/sgml/docbook/sgml/catalog was not found in the
> centralized catalog /etc/sgml/catalog
> + building "docbook-sgml" version "4.5" in /usr/src/sgml

Same as above. Even if old sgml directory infrastructure may not exist it 
may be possible that the paths remain in catalog file. It is better to 
force remove them to keep catalog file clean and with valid paths only.
It's clearness and being valid are more important than directory 
infrastructure because here sgml/xml application looks first. These 
warnings are harmless because they say that the path we remove is already 
not present. To stop this warning showing up someone needs to grep catalog 
looking for path and execute install-catalog only if path is present.

It is better to write global Lunar plugin/function for checking files for 
path presence. Such generic Lunar plugin would be helpful not only in sgml 
module but for example in every font module to update x.org file with font 
path. This could be the beginning of new *.conf option updater plugin. 
 
> And docbook-utils still fails with the same errors as before.

I'm not sure if you have lined recent docbook-sgml. In post_install there 
is special code which fixes self looping which causes build error in 
docbook-utils and possibly other future modules. I copied this fix code to 
pre_build of docbook-utils to add additional protection against this bug.
Do: lin -c docbook-sgml openjade docbook-utils.

have a nice day,
Zbigniew Luszpinski

From samuel.verstraete at gmail.com  Wed Sep  8 07:09:23 2010
From: samuel.verstraete at gmail.com (samuel)
Date: Wed, 8 Sep 2010 07:09:23 +0200
Subject: [Lunar-commits] <moonbase> docbook-sgml, xml: fixed build on
	64bit Lunars I installed 64bit Lunar (1.6.5 64bit iso) and reproduced
	reported issues on 64bit Lunars. Whole docbook-profile module compiled
	after clean install of iso. The compilation 
Message-ID: <AANLkTikvEUurE+8QpooO9CrfUib5Si+qv3zGr=OuBS3s@mail.gmail.com>

On Wed, Sep 8, 2010 at 1:49 AM, Zbigniew Luszpinski <zbiggy at o2.pl> wrote:
>> There are still some issues here with docbook-sgml. Though it does now
>> compile fine these need tending;
>>
>> ls: cannot access /usr/share/sgml/docbook/3*: No such file or directory
>> ls: cannot access /usr/share/sgml/docbook/4*: No such file or directory
>> ls: cannot access /usr/share/sgml/docbook/docbook-sgml*: No such file
>> or directory
>
> These are used to find and remove old sgml dirs (those created before my
> sgml/xml patch entered moonbase). These are totally safe and harmless.
> If ls will not find old dirs like you see here they will be not removed
> because they do not exist.

you can perfectly test  in advance if these directories exist or not.
then we won't see these errors.

From duncan.gibson at xs4all.nl  Wed Sep  8 08:37:54 2010
From: duncan.gibson at xs4all.nl (Duncan Gibson)
Date: Wed, 8 Sep 2010 08:37:54 +0200
Subject: [Lunar-commits] <moonbase> docbook-sgml,
	xml: fixed build on 64bit Lunars I installed 64bit Lunar (1.6.5 64bit 
	iso) and reproduced reported issues on 64bit Lunars. Whole 
	docbook-profile module compiled after clean install of iso. The 
	compilation went fine. No build errors.
In-Reply-To: <201009080149.27346.zbiggy@o2.pl>
References: <20100906005936.6207B9B223@doppio.foo-projects.org>
	<201009060658.03385.dennisveatch@bellsouth.net>
	<201009080149.27346.zbiggy@o2.pl>
Message-ID: <6459f70ea41ac2e1db2a9359a195ebab.squirrel@webmail.xs4all.nl>

>> There are still some issues here with docbook-sgml. Though it does now
>> compile fine these need tending;
>>
>> ls: cannot access /usr/share/sgml/docbook/3*: No such file or directory
>> ls: cannot access /usr/share/sgml/docbook/4*: No such file or directory
>> ls: cannot access /usr/share/sgml/docbook/docbook-sgml*: No such file
>> or directory

> These are used to find and remove old sgml dirs (those created before my
> sgml/xml patch entered moonbase). These are totally safe and harmless.
> If ls will not find old dirs like you see here they will be not removed
> because they do not exist.

Are you sure? IIRC, when building something required by the gnome2 profile,
after a fresh 1.6.5 install on X86_84, the build failed because the module
was using 3.1 or 3.2 DTD and hence needed the now missing directories.
The easiest way to work round it was to build with --disable-gtk-doc.

I don't remember which module it was because gnome2 involves rather a lot
of dependencies, and it might just be a coincidence. When I get home after
work I can check the /var/state/lunar/depends* files for --disable-gtk-doc
and see whether I can shed any light on which module(s) had this problem.

Cheers
Duncan / engelsman


From zbiggy at o2.pl  Sat Sep 11 21:10:46 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sat, 11 Sep 2010 21:10:46 +0200
Subject: [Lunar-commits] <moonbase> docbook-sgml,
	xml: fixed build on 64bit Lunars I installed 64bit Lunar (1.6.5 64bit
	iso) and reproduced reported issues on 64bit Lunars. Whole
	docbook-profile module compiled after clean install of iso. The
	compilation went fine. No build errors.
In-Reply-To: <6459f70ea41ac2e1db2a9359a195ebab.squirrel@webmail.xs4all.nl>
References: <20100906005936.6207B9B223@doppio.foo-projects.org>
	<201009080149.27346.zbiggy@o2.pl>
	<6459f70ea41ac2e1db2a9359a195ebab.squirrel@webmail.xs4all.nl>
Message-ID: <201009112110.56158.zbiggy@o2.pl>

> >> There are still some issues here with docbook-sgml. Though it does
> >> now compile fine these need tending;
> >> 
> >> ls: cannot access /usr/share/sgml/docbook/3*: No such file or
> >> directory ls: cannot access /usr/share/sgml/docbook/4*: No such
> >> file or directory ls: cannot access
> >> /usr/share/sgml/docbook/docbook-sgml*: No such file or directory
> > 
> > These are used to find and remove old sgml dirs (those created before
> > my sgml/xml patch entered moonbase). These are totally safe and
> > harmless. If ls will not find old dirs like you see here they will
> > be not removed because they do not exist.
> 
> Are you sure? IIRC, when building something required by the gnome2
> profile, after a fresh 1.6.5 install on X86_84, the build failed
> because the module was using 3.1 or 3.2 DTD and hence needed the now
> missing directories. The easiest way to work round it was to build
> with --disable-gtk-doc.

Yes I'm sure. I hope you have done lunar update before building anything.
Reporting bugs for old moonbase installed by iso makes no sense - I hope 
you know it. dobook-sgml installs all DTDs collected from all modules. 3.1 
is installed, 3.2 is not. If you tell me which module uses DTD 3.2 or 
other DTD not installed yet I will add it. Using workaround is your 
decision, however you should report broken module to the Lunar community 
so someone could fix it. Not reporting broken modules kills Lunar because 
you have done workaround but next person will simply drop Lunar because it 
does not compile.

> I don't remember which module it was because gnome2 involves rather a
> lot of dependencies, and it might just be a coincidence. When I get
> home after work I can check the /var/state/lunar/depends* files for
> --disable-gtk-doc and see whether I can shed any light on which
> module(s) had this problem.

I have build gtk-doc on 64bit iso and it compiles fine. I consider your 
bug report as false positive.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100911/fc2a7601/attachment.bin>

From duncan.gibson at xs4all.nl  Sun Sep 12 16:21:52 2010
From: duncan.gibson at xs4all.nl (Duncan Gibson)
Date: Sun, 12 Sep 2010 16:21:52 +0200
Subject: [Lunar-commits] <moonbase> docbook-sgml, xml: fixed build...
In-Reply-To: <201009112110.56158.zbiggy@o2.pl>
References: <20100906005936.6207B9B223@doppio.foo-projects.org>
	<201009080149.27346.zbiggy@o2.pl>
	<6459f70ea41ac2e1db2a9359a195ebab.squirrel@webmail.xs4all.nl>
	<201009112110.56158.zbiggy@o2.pl>
Message-ID: <a8b6b19cbbf3ed994b0d48646e837878.squirrel@webmail.xs4all.nl>

Re: [Lunar-commits] <moonbase> docbook-sgml, xml: fixed build on 64bit
Lunars I installed 64bit Lunar (1.6.5 64bit iso) and reproduced reported
issues on 64bit Lunars. Whole docbook-profile module compiled after clean
install of iso. The compilation went fine. No build errors.

>> Are you sure? IIRC, when building something required by the gnome2
>> profile, after a fresh 1.6.5 install on X86_84, the build failed
>> because the module was using 3.1 or 3.2 DTD and hence needed the now
>> missing directories. The easiest way to work round it was to build
>> with --disable-gtk-doc.

> Yes I'm sure. I hope you have done lunar update before building anything.
> Reporting bugs for old moonbase installed by iso makes no sense - I hope
> you know it. dobook-sgml installs all DTDs collected from all modules. 3.1
> is installed, 3.2 is not. If you tell me which module uses DTD 3.2 or
> other DTD not installed yet I will add it. Using workaround is your
> decision, however you should report broken module to the Lunar community
> so someone could fix it. Not reporting broken modules kills Lunar because
> you have done workaround but next person will simply drop Lunar because it
> does not compile.

Yes, of course I had done a lunar update. I didn't report this on the
BugTracker because everyone on #lunar had encountered problems with the
docbook update, so I assumed that it was still a work in progress.
However, I did report BR432 which appeared to be resolved after your
workaround on the mailing list.

>> I don't remember which module it was because gnome2 involves rather a
>> lot of dependencies, and it might just be a coincidence. When I get
>> home after work I can check the /var/state/lunar/depends* files for
>> --disable-gtk-doc and see whether I can shed any light on which
>> module(s) had this problem.

I think I confused previous gnome testing with the ISO install, and was
unable to reproduce the error for the modules in /var/state/lunar/depends
that had --disable-gtk-doc set (hal, gnome-vfs and PolicyKit-gnome IIRC)

So now I've reinstalled the machine again from scratch, and am unable to
install gnome2 because docbook-utils generates a BUILD error.

I have filed this as http://bugs.lunar-linux.org/view.php?id=435 and
have attached the activity log to show what else I have installed,
and in what order.

Cheers
D.


From zbiggy at o2.pl  Sun Sep 12 17:53:22 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sun, 12 Sep 2010 17:53:22 +0200
Subject: [Lunar-commits] <moonbase> docbook-sgml, xml: fixed build...
In-Reply-To: <a8b6b19cbbf3ed994b0d48646e837878.squirrel@webmail.xs4all.nl>
References: <20100906005936.6207B9B223@doppio.foo-projects.org>
	<201009112110.56158.zbiggy@o2.pl>
	<a8b6b19cbbf3ed994b0d48646e837878.squirrel@webmail.xs4all.nl>
Message-ID: <201009121753.44476.zbiggy@o2.pl>

> >> I don't remember which module it was because gnome2 involves rather
> >> a lot of dependencies, and it might just be a coincidence. When I
> >> get home after work I can check the /var/state/lunar/depends* files
> >> for --disable-gtk-doc and see whether I can shed any light on which
> >> module(s) had this problem.
> 
> I think I confused previous gnome testing with the ISO install, and was
> unable to reproduce the error for the modules in
> /var/state/lunar/depends that had --disable-gtk-doc set (hal,
> gnome-vfs and PolicyKit-gnome IIRC)
> 
> So now I've reinstalled the machine again from scratch, and am unable
> to install gnome2 because docbook-utils generates a BUILD error.
> 
> I have filed this as http://bugs.lunar-linux.org/view.php?id=435 and
> have attached the activity log to show what else I have installed,
> and in what order.

I fixed docbook-utils issue 21 hours ago. Do you have recent moonbase? 
Also managed to reproduce the gtk-doc issue you were talking about -fixed.
It was only visible when xmlto was installed before gtk-doc.

Currently I do not seen any issues with docbook. docbook-profile, gtk-doc, 
xextproto with xmlto installed as first compiled fine.

30 minutes ago I commited the last updates to docbook which resolves 
remaining issues.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100912/08c66de9/attachment.bin>

From auke at foo-projects.org  Fri Sep 17 07:17:20 2010
From: auke at foo-projects.org (Auke Kok)
Date: Thu, 16 Sep 2010 22:17:20 -0700
Subject: [Lunar-commits] <moonbase> qt4: Adjusting the BUILD to fix an
	issue	with libQtClucene.so.4 not found
In-Reply-To: <20100908233619.06E2E9B2E8@doppio.foo-projects.org>
References: <20100908233619.06E2E9B2E8@doppio.foo-projects.org>
Message-ID: <4C92F9E0.7010709@foo-projects.org>

On 09/08/2010 04:35 PM, Dennis `stumbles` Veatch wrote:
> commit 1a6642f1461bf1763e35d20b0801804c5e544df8
> Author: Dennis `stumbles` Veatch<stumbles at lunar-linux.org>
> Date:   Wed Sep 8 19:35:18 2010 -0400
>
>      qt4: Adjusting the BUILD to fix an issue with libQtClucene.so.4 not found
>
>      as noted in IRC by Hirager.
>
>      Thanks.
> ---
>   qt4-apps/qt4/BUILD |   26 +++++++++++++-------------
>   1 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/qt4-apps/qt4/BUILD b/qt4-apps/qt4/BUILD
> index 023127a..a9aa537 100644
> --- a/qt4-apps/qt4/BUILD
> +++ b/qt4-apps/qt4/BUILD
> @@ -1,8 +1,8 @@
>   (
>
> -  export QTDIR=${MODULE_PREFIX}
> -  export PATH=$QTDIR/bin:$PATH
> -  export LD_LIBRARY_PATH=$QTDIR/lib
> +  export QTDIR=$SOURCE_DIRECTORY&&
> +  export PATH=$QTDIR/bin:$PATH&&
> +  export LD_LIBRARY_PATH=$QTDIR/lib&&
>
>     sedit "s:COMMERCIAL_USER=ask:COMMERCIAL_USER=no:" configure&&
>     sedit "s/-O2/$CFLAGS/" mkspecs/common/g++.conf&&
> @@ -17,16 +17,16 @@
>
>     OPTS="-largefile -multimedia -audio-backend -no-separate-debug-info -script -release -scripttools -accessibility -glib -optimized-qmake -no-phonon -xmlpatterns -fast -shared"&&
>
> -  echo "yes" | ./configure                             \
> -               -prefix ${QTDIR}                        \
> -               -docdir ${QTDIR}/share/$MODULE          \
> -               -plugindir /opt/lunar/plugins/qt4       \
> -               -datadir ${QTDIR}/share/$MODULE         \
> -               -translationdir ${QTDIR}/share/$MODULE  \
> -               -sysconfdir /etc/$MODULE/               \
> -               -examplesdir ${QTDIR}/share/$MODULE     \
> -               -demosdir ${QTDIR}/share/$MODULE        \
> -               $OPTS&&
> +  echo "yes" | ./configure                                     \
> +               -prefix ${MODULE_PREFIX}                        \
> +               -docdir ${MODULE_PREFIX}/share/$MODULE          \
> +               -plugindir /opt/lunar/plugins/qt4               \


qt plugins aren't browser plugins... in any case, do me a favor and move 
these to:

	-plugindir /usr/lib/qt4/plugins

which is probably the best place to put them.

Auke

From dennisveatch at bellsouth.net  Mon Sep 20 01:39:34 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Sun, 19 Sep 2010 19:39:34 -0400
Subject: [Lunar-commits] <moonbase> docbook-xsl: fix for kdelibs4
	documentation build
In-Reply-To: <20100919225422.EAF959B2C9@doppio.foo-projects.org>
References: <20100919225422.EAF959B2C9@doppio.foo-projects.org>
Message-ID: <201009191939.35003.dennisveatch@bellsouth.net>

On Sunday 19 September 2010 8:52:50 pm Zbigniew Luszpinski wrote:
> commit d839848966cfe775c0a5e155c0d4058450d6d92e
> Author: Zbigniew Luszpinski <zbiggy at lunar-linux.org>
> Date:   Mon Sep 20 00:52:50 2010 +0000
> 
>     docbook-xsl: fix for kdelibs4 documentation build
> ---
>  doc-tools/docbook-xsl/BUILD |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/doc-tools/docbook-xsl/BUILD b/doc-tools/docbook-xsl/BUILD
> index f3bff99..8de9014 100644
> --- a/doc-tools/docbook-xsl/BUILD
> +++ b/doc-tools/docbook-xsl/BUILD
> @@ -11,4 +11,8 @@
> 
>    cp -a $SOURCE_DIRECTORY/* $TARGET/
> 
> +  # Add default, version independent location (fixes kdelibs4)
> +  mkdir -p /usr/share/xml/docbook/stylesheet &&
> +  ln -sf $TARGET /usr/share/xml/docbook/stylesheet/docbook-xsl
> +
>  ) > $C_FIFO 2>&1
> _______________________________________________

Is that really needed? Commit 1fba69dad992a377e3c773e12846d853c9e15421 took 
care of the xsl issue;

-- Found LibXslt: /usr/lib64/libxslt.so
-- Found DocBookXSL: /usr/share/sgml/docbook/xsl-stylesheets-1.76.0 
[  2%] Building CXX object kdoctools/CMakeFiles/meinproc4_simple.dir/xslt.o
Building CXX object kdoctools/CMakeFiles/meinproc4.dir/xslt.o
[ 24%] Building CXX object kdoctools/CMakeFiles/meinproc4.dir/xslt_kde.o
Building CXX object kdoctools/CMakeFiles/kio_help.dir/xslt.o
[ 58%] Building CXX object kdoctools/CMakeFiles/kio_help.dir/xslt_help.o
[ 58%] Building CXX object kdoctools/CMakeFiles/kio_ghelp.dir/xslt.o
Building CXX object kdoctools/CMakeFiles/kio_ghelp.dir/xslt_help.o
[ 58%] Building CXX object kdoctools/CMakeFiles/kio_help.dir/xslt_kde.o
Building CXX object kdoctools/CMakeFiles/kio_ghelp.dir/xslt_kde.o
-- Installing: /usr/share/apps/ksgmltools2/docbook/xsl/README
-- Installing: /usr/share/apps/ksgmltools2/docbook/xsl/VERSION

and so one and the compile is fine.

-- 
Dennis Veatch

From zbiggy at o2.pl  Sun Sep 26 02:18:20 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sun, 26 Sep 2010 00:18:20 +0000
Subject: [Lunar-commits] <moonbase> docbook-xsl: fix for kdelibs4
	documentation build
In-Reply-To: <201009191939.35003.dennisveatch@bellsouth.net>
References: <20100919225422.EAF959B2C9@doppio.foo-projects.org>
	<201009191939.35003.dennisveatch@bellsouth.net>
Message-ID: <201009260018.42401.zbiggy@o2.pl>

> On Sunday 19 September 2010 8:52:50 pm Zbigniew Luszpinski wrote:
> > commit d839848966cfe775c0a5e155c0d4058450d6d92e
> > Author: Zbigniew Luszpinski <zbiggy at lunar-linux.org>
> > Date:   Mon Sep 20 00:52:50 2010 +0000
> > 
> >     docbook-xsl: fix for kdelibs4 documentation build
> > 
> > ---
> > 
> >  doc-tools/docbook-xsl/BUILD |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/doc-tools/docbook-xsl/BUILD
> > b/doc-tools/docbook-xsl/BUILD index f3bff99..8de9014 100644
> > --- a/doc-tools/docbook-xsl/BUILD
> > +++ b/doc-tools/docbook-xsl/BUILD
> > @@ -11,4 +11,8 @@
> > 
> >    cp -a $SOURCE_DIRECTORY/* $TARGET/
> > 
> > +  # Add default, version independent location (fixes kdelibs4)
> > +  mkdir -p /usr/share/xml/docbook/stylesheet &&
> > +  ln -sf $TARGET /usr/share/xml/docbook/stylesheet/docbook-xsl
> > +
> > 
> >  ) > $C_FIFO 2>&1
> > 
> > _______________________________________________
> 
> Is that really needed? Commit 1fba69dad992a377e3c773e12846d853c9e15421
> took care of the xsl issue;
> 
> -- Found LibXslt: /usr/lib64/libxslt.so
> -- Found DocBookXSL: /usr/share/sgml/docbook/xsl-stylesheets-1.76.0
> [  2%] Building CXX object
> kdoctools/CMakeFiles/meinproc4_simple.dir/xslt.o Building CXX object
> kdoctools/CMakeFiles/meinproc4.dir/xslt.o
> [ 24%] Building CXX object
> kdoctools/CMakeFiles/meinproc4.dir/xslt_kde.o Building CXX object
> kdoctools/CMakeFiles/kio_help.dir/xslt.o
> [ 58%] Building CXX object
> kdoctools/CMakeFiles/kio_help.dir/xslt_help.o [ 58%] Building CXX
> object kdoctools/CMakeFiles/kio_ghelp.dir/xslt.o Building CXX object
> kdoctools/CMakeFiles/kio_ghelp.dir/xslt_help.o [ 58%] Building CXX
> object kdoctools/CMakeFiles/kio_help.dir/xslt_kde.o Building CXX
> object kdoctools/CMakeFiles/kio_ghelp.dir/xslt_kde.o -- Installing:
> /usr/share/apps/ksgmltools2/docbook/xsl/README
> -- Installing: /usr/share/apps/ksgmltools2/docbook/xsl/VERSION
> 
> and so one and the compile is fine.

OK reverted. I downloaded moonbase one day before your commit and was busy 
building and fixing new Lunar. Haven't noticed your patch.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100926/186209d7/attachment.bin>

From zbiggy at o2.pl  Mon Sep 27 01:19:50 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sun, 26 Sep 2010 23:19:50 +0000
Subject: Changes to lunar optimize
Message-ID: <201009262319.56541.zbiggy@o2.pl>

Hello,

here are my proposed changes to lunar optimize:
-O3 Fastest
*Move it to "Specialized optimizations" because it is not safe or fastest:
*It is not true it is the fastest it _may_ _be_ faster or slower than -O2
depending on code. So rename it to may be "slower/faster than -O2". 
Setting it distribution wide is dangerous. Firefox, Seamonkey, Thunderbird 
will compile well but crash on start with segmentation fault because -O3 
will enable -ftree-vectorize - silent runtime killer for C++ applications.
-ftree-vectorize is silent and dangerous killer because:
*it does not kill an application compiled with it but libraries on which 
it depends kill it. In case of mozilla apps you can build them with ftree-
vectorize and they will work. Build zlib, jpeg, cairo and other libs 
mozilla use with -ftree-vectorize and they will cause mozilla apps crash 
on start.
*You can rebuild lunar with it and it will compile and work but some C++ 
applications will be crashing on start and you will have really hard task 
to find why they crash.
* -O3 can cause the code to grow up insanely and eat memory and disk space 
like a crazy. This is one of the reasons making -O3 actually slower than -
O2.

Newbies will always choose -O3 because the fastest is better than faster -
O2 and will end up with broken system.  Next they will leave Lunar with 
opinion too buggy to use.

cpu selection in safe mode should be limited to:
-i686
-native
only. The first one is paranoid safe and slow, the second one is really 
safe and the fastest.
On Lunar general ML I presented a proof that shows native target is better 
than manually selecting CPU. If newbie will choose bad cpu broken system 
will be compiled.

linker:
I would like to add these optional flags to speed up app loading:
-Wl,--hash-style-gnu=both
-Wl,--sort-common
I have successfuly rebuilt lunar 1.6.5 32bit with KDE and mozilla using 
these flags so they are safe.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100926/a9a641db/attachment.bin>

From auke at foo-projects.org  Mon Sep 27 08:17:31 2010
From: auke at foo-projects.org (Auke Kok)
Date: Sun, 26 Sep 2010 23:17:31 -0700
Subject: Changes to lunar optimize
In-Reply-To: <201009262319.56541.zbiggy@o2.pl>
References: <201009262319.56541.zbiggy@o2.pl>
Message-ID: <4CA036FB.7070907@foo-projects.org>

On 09/26/2010 04:19 PM, Zbigniew Luszpinski wrote:
> Hello,
>
> here are my proposed changes to lunar optimize:
> -O3 Fastest
> *Move it to "Specialized optimizations" because it is not safe or fastest:
> *It is not true it is the fastest it _may_ _be_ faster or slower than -O2
> depending on code. So rename it to may be "slower/faster than -O2".
> Setting it distribution wide is dangerous. Firefox, Seamonkey, Thunderbird
> will compile well but crash on start with segmentation fault because -O3
> will enable -ftree-vectorize - silent runtime killer for C++ applications.
> -ftree-vectorize is silent and dangerous killer because:
> *it does not kill an application compiled with it but libraries on which
> it depends kill it. In case of mozilla apps you can build them with ftree-
> vectorize and they will work. Build zlib, jpeg, cairo and other libs
> mozilla use with -ftree-vectorize and they will cause mozilla apps crash
> on start.
> *You can rebuild lunar with it and it will compile and work but some C++
> applications will be crashing on start and you will have really hard task
> to find why they crash.
> * -O3 can cause the code to grow up insanely and eat memory and disk space
> like a crazy. This is one of the reasons making -O3 actually slower than -
> O2.
>
> Newbies will always choose -O3 because the fastest is better than faster -
> O2 and will end up with broken system.  Next they will leave Lunar with
> opinion too buggy to use.

why not just hide the option when "only show safe optimizations" is set? 
This is far more simple to implement and keeps the option in a logical 
location.

> cpu selection in safe mode should be limited to:
> -i686
> -native
> only. The first one is paranoid safe and slow, the second one is really
> safe and the fastest.

well, I'd argue that -i586 would be even safer than i686, but in reality 
the only safe optimization is -march=native or nothing else, and that's 
certainly acceptable. So lets (in safe mode) only show:

    ( ) none
    (x) native

> On Lunar general ML I presented a proof that shows native target is better
> than manually selecting CPU. If newbie will choose bad cpu broken system
> will be compiled.

a script will always know best :)

Also, in your POC your compiler isn't enabling -fpmath=... I wonder why, 
perhaps that's different per CPU whether it's worth it or not.

> linker:
> I would like to add these optional flags to speed up app loading:
> -Wl,--hash-style-gnu=both
> -Wl,--sort-common
> I have successfuly rebuilt lunar 1.6.5 32bit with KDE and mozilla using
> these flags so they are safe.

that's not sufficient proof that these flags are indeed safe...

However, I'd have no problems adding these to the non-safe list.


Auke

From zbiggy at o2.pl  Mon Sep 27 15:56:12 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Mon, 27 Sep 2010 13:56:12 +0000
Subject: Changes to lunar optimize
In-Reply-To: <4CA036FB.7070907@foo-projects.org>
References: <201009262319.56541.zbiggy@o2.pl>
	<4CA036FB.7070907@foo-projects.org>
Message-ID: <201009271356.12764.zbiggy@o2.pl>

> > cpu selection in safe mode should be limited to:
> > -i686
> > -native
> > only. The first one is paranoid safe and slow, the second one is
> > really safe and the fastest.
> 
> well, I'd argue that -i586 would be even safer than i686, but in
> reality the only safe optimization is -march=native or nothing else,
> and that's certainly acceptable. So lets (in safe mode) only show:
> 
>     ( ) none
>     (x) native

-march=i586 and below will be less safe. Lunar 32bit is compiled for i686 
target. Going below main arch is not safe however not much. That is why on 
32bit Lunar ( ) none target == -march=pentiumpro == -march=i686. You can 
test this using empty export TESTFLAGS="" parameter in script presented in 
PoC.

man gcc says:
pentiumpro
Intel PentiumPro CPU.

i686
Same as "generic", but when used as "march" option, PentiumPro instruction 
set will be used, so the code will run on all i686 family chips.

> > On Lunar general ML I presented a proof that shows native target is
> > better than manually selecting CPU. If newbie will choose bad cpu
> > broken system will be compiled.
> 
> a script will always know best :)
> 
> Also, in your POC your compiler isn't enabling -fpmath=... I wonder
> why, perhaps that's different per CPU whether it's worth it or not.

mfpmath is enabled by default: man gcc - for 32bit =387 for 64bit =sse.
This test script shows only settings set via gcc parameter manually or 
march= option which expands itself to other flags like msse m3dnow or mmmx  
It does not show what is set by default.

have a nice day,
Zbigniew Luszpinski

From auke at foo-projects.org  Tue Sep 28 02:36:58 2010
From: auke at foo-projects.org (Auke Kok)
Date: Mon, 27 Sep 2010 17:36:58 -0700
Subject: [Lunar-commits] <moonbase> NVIDIA(beta): remove outdated GL header
	files. This patch removes all GL headers which were installed	by Nvidia
	to
	protect users against the junk they contain.	Since new driver release
	Nvidia
	stops including any include	files. When I analyzed the content of
	Nvidia
	GL headers I	realized this is old crap. The most ugly was gl.h - it
	was	designed exclusively for M$ Windows not Linux!
In-Reply-To: <20100927235218.333079B2E8@doppio.foo-projects.org>
References: <20100927235218.333079B2E8@doppio.foo-projects.org>
Message-ID: <4CA138AA.3000604@foo-projects.org>

On 09/27/2010 06:45 PM, Zbigniew Luszpinski wrote:
> commit ebfc7555ebab411dcd79e75be290edf81ded6b96
> Author: Zbigniew Luszpinski<zbiggy at lunar-linux.org>
> Date:   Tue Sep 28 01:45:07 2010 +0000
>
>      NVIDIA(beta): remove outdated GL header files.
>      This patch removes all GL headers which were installed by Nvidia
>      to protect users against the junk they contain.
>      Since new driver release Nvidia stops including any include files.
>      When I analyzed the content of Nvidia GL headers I realized this is old crap.
>      The most ugly was gl.h - it was designed exclusively for M$ Windows not Linux!

good catch, we should have never installed these to begin with...

perhaps someone wants to audit fglrx?

Auke

From samuel.verstraete at gmail.com  Tue Sep 28 12:21:19 2010
From: samuel.verstraete at gmail.com (samuel)
Date: Tue, 28 Sep 2010 12:21:19 +0200
Subject: [Lunar-commits] <moonbase> NVIDIA(beta): remove outdated GL
	header files. This patch removes all GL headers which were installed by
	Nvidia to protect users against the junk they contain. Since new driver
	release Nvidia stops including any include
Message-ID: <AANLkTi=7tE9A2adZ-P4TPyzQwKKGqMaGbZV7e6OLyeDU@mail.gmail.com>

fglrx hasn't been working for ages... imho we should just remove it from
moonbase

On Tue, Sep 28, 2010 at 2:36 AM, Auke Kok <auke at foo-projects.org> wrote:

> On 09/27/2010 06:45 PM, Zbigniew Luszpinski wrote:
>
>> commit ebfc7555ebab411dcd79e75be290edf81ded6b96
>> Author: Zbigniew Luszpinski<zbiggy at lunar-linux.org>
>> Date:   Tue Sep 28 01:45:07 2010 +0000
>>
>>     NVIDIA(beta): remove outdated GL header files.
>>     This patch removes all GL headers which were installed by Nvidia
>>     to protect users against the junk they contain.
>>     Since new driver release Nvidia stops including any include files.
>>     When I analyzed the content of Nvidia GL headers I realized this is
>> old crap.
>>     The most ugly was gl.h - it was designed exclusively for M$ Windows
>> not Linux!
>>
>
> good catch, we should have never installed these to begin with...
>
> perhaps someone wants to audit fglrx?
>
> Auke
>
> _______________________________________________
> Lunar-commits mailing list
> Lunar-commits at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100928/3a157250/attachment.html>

From zbiggy at o2.pl  Wed Sep 29 02:35:24 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Wed, 29 Sep 2010 00:35:24 +0000
Subject: [Lunar-commits] <moonbase> NVIDIA(beta): remove outdated GL
	header files. This patch removes all GL headers which were
	installed by Nvidia to protect users against the junk they
	contain. Since new driver release Nvidia stops including any include
In-Reply-To: <AANLkTi=7tE9A2adZ-P4TPyzQwKKGqMaGbZV7e6OLyeDU@mail.gmail.com>
References: <AANLkTi=7tE9A2adZ-P4TPyzQwKKGqMaGbZV7e6OLyeDU@mail.gmail.com>
Message-ID: <201009290035.24413.zbiggy@o2.pl>

> fglrx hasn't been working for ages... imho we should just remove it

There is no Lunar developers using Radeon?
AFAIR fglrx provides no headers at all so no worry here.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100929/318f2afb/attachment.bin>

From jean.bruenn at ip-minds.de  Wed Sep 29 13:35:11 2010
From: jean.bruenn at ip-minds.de (Jean-Michel Bruenn)
Date: Wed, 29 Sep 2010 13:35:11 +0200
Subject: Lunar optimize Bug
Message-ID: <20100929133511.33ffc6ad.jean.bruenn@ip-minds.de>

Hello,

someone implemented a bug into lunar optimize i think. Previously, when
running "lunar optimize" and you selected "safe => on" at gcc you were
able to only select cc_opt, cpu and bopt. Now i'm able to select bopt,
cpu, xtra, spd, fpm and cc_opt (so yes, i can access specialized
optimizations, floating point optimizations, etc while beeing in
"safe") - At "cpu" i can only select "native". So something is going
wrong. Selection of fpu, specialized optimizations, etc shouldnt work
while beeing in safe.

or?

Cheers
wdp

-- 
Jean-Michel Bruenn <jean.bruenn at ip-minds.de>

From samuel.verstraete at gmail.com  Wed Sep 29 12:53:44 2010
From: samuel.verstraete at gmail.com (samuel)
Date: Wed, 29 Sep 2010 12:53:44 +0200
Subject: [Lunar-commits] <moonbase> NVIDIA(beta): remove outdated GL
	header files. This patch removes all GL headers which were installed by
	Nvidia to protect users against the junk they contain. Since new driver
	release Nvidia stops including any include
In-Reply-To: <201009290035.24413.zbiggy@o2.pl>
References: <AANLkTi=7tE9A2adZ-P4TPyzQwKKGqMaGbZV7e6OLyeDU@mail.gmail.com>
	<201009290035.24413.zbiggy@o2.pl>
Message-ID: <AANLkTi=9FVmruV6gXyaOk5GJP=WQoNnfehf2YK+8JgLd@mail.gmail.com>

ever since i bought an AMD/ATI card i have used the xf86-video-ati driver...
It more than satisfied my needs... I don't think anyone else has amd/ati
cards

On Wed, Sep 29, 2010 at 2:35 AM, Zbigniew Luszpinski <zbiggy at o2.pl> wrote:

> > fglrx hasn't been working for ages... imho we should just remove it
>
> There is no Lunar developers using Radeon?
> AFAIR fglrx provides no headers at all so no worry here.
>
> have a nice day,
> Zbigniew Luszpinski
>
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100929/9823f95a/attachment.html>

From auke at foo-projects.org  Wed Sep 29 17:39:34 2010
From: auke at foo-projects.org (Auke Kok)
Date: Wed, 29 Sep 2010 08:39:34 -0700
Subject: Lunar optimize Bug
In-Reply-To: <20100929133511.33ffc6ad.jean.bruenn@ip-minds.de>
References: <20100929133511.33ffc6ad.jean.bruenn@ip-minds.de>
Message-ID: <4CA35DB6.8010905@foo-projects.org>

On 09/29/2010 04:35 AM, Jean-Michel Bruenn wrote:
> unar optimize i think. Previously, when
> running "lunar optimize" and you selected "safe =>  on" at gcc you were
> able to only select cc_opt, cpu and bopt. Now i'm able to select bopt,
> cpu, xtra, spd, fpm and cc_opt (so yes, i can access specialized
> optimizations, floating point optimizations, etc while beeing in
> "safe") - At "cpu" i can only select "native". So something is going
> wrong. Selection of fpu, specialized optimizations, etc shouldnt work
> while beeing in safe.

it's intended. instead of hiding all the menu's, most of the 
optimizations in the speed menu (for instance) are actually safe. Even 
gcc turns most of them on when you use -O2, as I annotated in the source 
code.

I did a full screen of all the options, and everything that's visible 
now with "safe" on is really very safe.

Auke


From jean.bruenn at ip-minds.de  Wed Sep 29 20:09:32 2010
From: jean.bruenn at ip-minds.de (Jean-Michel Bruenn)
Date: Wed, 29 Sep 2010 20:09:32 +0200
Subject: Lunar optimize Bug
In-Reply-To: <4CA35DB6.8010905@foo-projects.org>
References: <20100929133511.33ffc6ad.jean.bruenn@ip-minds.de>
	<4CA35DB6.8010905@foo-projects.org>
Message-ID: <20100929200932.fa37dce2.jean.bruenn@ip-minds.de>

> it's intended. instead of hiding all the menu's, most of the 
> optimizations in the speed menu (for instance) are actually safe. Even 
> gcc turns most of them on when you use -O2, as I annotated in the source 
> code.
> 
> I did a full screen of all the options, and everything that's visible 
> now with "safe" on is really very safe.
> 
> Auke

I'm unsure about that (As i and some other users had some issues for
example with SSE enabled, all of our cpus have the sse flags - While i
have my whole netbook (intel atom) compiled with sse enabled without
problems, my desktop (amd cpu, which supports up to sse3) can't compile
some things when the whole box is compiled with sse enabled (mainly
video related stuff, like x264, gpac, etc) - So i'd even say sse is
not safe, and applications which need it will enable it anyway if
supported, applications which don't enable it automatically will
probably won't use them at all - so no big deal.

However, thanks for pointing that out.

Jean

From auke at foo-projects.org  Wed Sep 29 21:29:26 2010
From: auke at foo-projects.org (Auke Kok)
Date: Wed, 29 Sep 2010 12:29:26 -0700
Subject: Lunar optimize Bug
In-Reply-To: <20100929200932.fa37dce2.jean.bruenn@ip-minds.de>
References: <20100929133511.33ffc6ad.jean.bruenn@ip-minds.de>	<4CA35DB6.8010905@foo-projects.org>
	<20100929200932.fa37dce2.jean.bruenn@ip-minds.de>
Message-ID: <4CA39396.7000807@foo-projects.org>

On 09/29/2010 11:09 AM, Jean-Michel Bruenn wrote:
>> it's intended. instead of hiding all the menu's, most of the
>> optimizations in the speed menu (for instance) are actually safe. Even
>> gcc turns most of them on when you use -O2, as I annotated in the source
>> code.
>>
>> I did a full screen of all the options, and everything that's visible
>> now with "safe" on is really very safe.
>>
>> Auke
>
> I'm unsure about that (As i and some other users had some issues for
> example with SSE enabled, all of our cpus have the sse flags - While i
> have my whole netbook (intel atom) compiled with sse enabled without
> problems, my desktop (amd cpu, which supports up to sse3) can't compile
> some things when the whole box is compiled with sse enabled (mainly
> video related stuff, like x264, gpac, etc) - So i'd even say sse is
> not safe, and applications which need it will enable it anyway if
> supported, applications which don't enable it automatically will
> probably won't use them at all - so no big deal.

most applications will never use sse optimizations, and x264 *should* 
really use it

the fact that x264 breaks is more an indication of the maturity of that 
product than a sign of unsafety of the -msseN flags... Video decoding 
really must rely heavily on these optimizations otherwise you're better 
off using MPEG2...

Auke