Bug 502024 - (xsd) Review Request: xsd - W3C XML schema to C++ data binding compiler
Review Request: xsd - W3C XML schema to C++ data binding compiler
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Mamoru TASAKA
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-21 10:53 EDT by Antti Andreimann
Modified: 2009-07-16 03:06 EDT (History)
7 users (show)

See Also:
Fixed In Version: 3.2.0-4.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-07 14:55:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mtasaka: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Antti Andreimann 2009-05-21 10:53:11 EDT
Spec URL: http://anttix.org/fedora/pkg/xsd.spec
SRPM URL: http://anttix.org/fedora/pkg/xsd-3.2.0-1.fc10.src.rpm

Description: 
CodeSynthesis XSD is an open-source, cross-platform W3C XML Schema to
C++ data binding compiler. Provided with an XML instance specification
(XML Schema), it generates C++ classes that represent the given
vocabulary as well as parsing and serialization code.
You can then access the data stored in XML using types and functions
that semantically correspond to your application domain rather than
dealing with intricacies of reading and writing XML.

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1368376

Known issues:
1. The doc sub-package has a two Postscript files that rpmlint grunts about
   not being in UTF-8 encoding. I couldn't find any reasonable converter that
   can convert Postscript files to another encoding and AFAIK many printers
   do not support UTF-8 at all.

2. The main package contains both: the xsd schema compiler and the header files
   needed to build the generated code. Rpmlint does not like it at all.
   However there is no value in separating headers from the compiler:
   if You use the compiler to generate C++ code, You most certainly want to
   build the generated files as well.

3. Compiler binary is renamed to xsdcxx to avoid a name conflict. The same 
   naming is currently used in the debian project
   (http://packages.debian.org/source/lenny/xsd).
Comment 1 Mamoru TASAKA 2009-05-27 13:25:59 EDT
! About Licensing:

- While most files in the source archives are under
  GPLv2+ with exceptions which contains the clause to
  allow the linkage against xerces-c which are under ASL 2.0,
  some files are strict GPLv2.

  Then with "verbose=yes", build.log shows (for example):
-------------------------------------------------------------------------
    96  g++  -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/arch/i386/i486/i586/i686 -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/arch/i386/i486/i586 -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/arch/i386/i486 -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/arch/i386 -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/arch/generic -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2 -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2  -I/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/../install/include    -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/arguments.o -c /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/arguments.cxx
   102  ar -rc /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/libcult.a /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/eh/exception.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/mm/new.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/mm/counter.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/mm/buffer.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/rtti/type-info.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/trace/log.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/arguments.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/file-arguments.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/scanner.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/options.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/options-parser.o /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.2/cult/cli/options-spec.o
   306  g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables     -o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/xsd /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/xsd.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/elements.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/elements.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/validator.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/name-processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/type-processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/state-processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/generator.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/parser-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/parser-inline.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/parser-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/parser-forward.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/impl-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/impl-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/driver-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/element-validation-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/attribute-validation-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/parser/characters-validation-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/elements.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/validator.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/counter.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/name-processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/generator.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/tree-forward.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/tree-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/tree-inline.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/tree-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/parser-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/parser-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/stream-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/stream-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/serialization-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/serialization-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/stream-insertion-header.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/stream-insertion-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/cxx/tree/stream-extraction-source.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/type-map/lexer.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/type-map/parser.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/processing/cardinality/processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/processing/inheritance/processor.o /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/../install/lib/libxsd-frontend.a /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/../install/lib/libcult.a /usr/lib/libboost_filesystem.so /usr/lib/libboost_regex.so /usr/lib/libxerces-c.so 
-------------------------------------------------------------------------
  Here
  - libcult-1.4.2/cult/cli/arguments.cxx is under GPLv2
  - Building xsd binary uses both 
    * libcult.a (which contains libcult-1.4.2/cult/cli/arguments.o),
      which is under GPLv2
    * and libxerces-c.so which is under ASL 2.0
  They are incompatible according to
  https://fedoraproject.org/wiki/Licensing

  I guess the possible way to resolve this license conflict is to
  relicense all files in this source tarball which are under GPLv2
  to GPLv2+ (or GPLv2+ with exceptions: note that ASL 2.0 is compatible
  with GPLv3)

Setting FE-Legal.
Comment 2 Tom "spot" Callaway 2009-05-27 14:32:44 EDT
> I guess the possible way to resolve this license conflict is to
> relicense all files in this source tarball which are under GPLv2
> to GPLv2+ (or GPLv2+ with exceptions: note that ASL 2.0 is compatible
> with GPLv3).

Either option would be acceptable, please reach out to upstream and have them correct it one way or the other.
Comment 3 Mamoru TASAKA 2009-06-14 12:36:04 EDT
Please let us know it when you receive some response from
the upsteam.
Comment 4 Antti Andreimann 2009-06-14 13:38:00 EDT
I sent upstream an e-mail today and will post the results here as soon as I get them. If they can not resolve the issue, I will remove the xsd compiler binary from the package until the issue is resolved (the headers are still useful for building applications that come with pre-generated binding code).
Comment 5 Antti Andreimann 2009-06-16 19:34:10 EDT
I received the following reply from Boris Kolpackov

======================================================
Thanks for your effort in packaging XSD for Fedora, it is very much
appreciated. Regarding the licensing issue, unfortunately relicensing
the code under "GPLv2 or later" is not an option at the moment and
making it "GPLv2 with exceptions" opens up a potential maintenance
problem. Let me explain: the files that are under GPLv2 are from the
base libraries that provide functionality that is not related to (nor
is aware of) Xerces-C++. In other words, code from, say libcult, is
used to parse command line arguments and just happens to be in the
same executable (xsdcxx) as code that uses Xerces-C++. Since this
GPLv2 code is not interacting in any way with the Xerces-C++ code
under ASL 2.0, my understanding of the licenses suggests that there
is no issue in having these two pieces of code in the same executable.

The problem with making this code "GPLv2 with exceptions for ASL 2.0"
is that tomorrow somebody else may start using libcult in their
program that uses another, incompatible with GPL, library. They
could then rightfully expect that we will add another exception
to the licensing condition. I think you see how this can quickly
get out of control.

Let me know if the above reasoning (the fact that the GPLv2 and ASL
code are completely independent) is acceptable to the reviewers. If
not then we will have to figure out another way.
======================================================

Well, his logic seems to be that since the libcult does not use xerces functionality, the licencse incompatibility between the two is not an issue. I'm not much of an expert on such border line licensing issues, but the logic here does seem to be similar to making a distribution: you can put different parts of the system in the same bag and distribute them together (as long as such distribution is permitted) even if the individual licenses conflict with each other. The xsd compiler binary is present in debian which has very strict licensing policies, but I don't know if debian maintainers have investigated the libcult vs xerces licensing issue.
Comment 6 Mamoru TASAKA 2009-06-19 13:07:52 EDT
(In reply to comment #5)
> I received the following reply from Boris Kolpackov
> 
> ======================================================
> Thanks for your effort in packaging XSD for Fedora, it is very much
> appreciated. Regarding the licensing issue, unfortunately relicensing
> the code under "GPLv2 or later" is not an option at the moment and
> making it "GPLv2 with exceptions" opens up a potential maintenance
> problem. Let me explain: the files that are under GPLv2 are from the
> base libraries that provide functionality that is not related to (nor
> is aware of) Xerces-C++. In other words, code from, say libcult, is
> used to parse command line arguments and just happens to be in the
> same executable (xsdcxx) as code that uses Xerces-C++. Since this
> GPLv2 code is not interacting in any way with the Xerces-C++ code
> under ASL 2.0, my understanding of the licenses suggests that there
> is no issue in having these two pieces of code in the same executable.

NO.
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
i.e. "Having these two pieces of code in the same executable" makes
      these all parts one big program and in this case all these codes
      must be GPLv2+ compatible.
Comment 7 Boris Kolpackov 2009-06-21 12:52:56 EDT
Here is a quote from the FSF page mentioned above:

"Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)."

My point is that there is no communications between GPL and ASL licensed modules. But then the next paragraph states:

"If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program."

So things are quite murky here and, I agree, it will be more straightforward to add an explicit allowance in the licensing conditions. However, instead of adding a provision just for Xerces-C++ or ASL, I will add a general provision that will allow combining the software in question with other incompatibly-licensed modules in a single program provided that there is no use of the functionality offered by the software by such modules. Here is the text that I will place into the LICENSE file (it is similar and is based on the wording from xsd):

-------------------------------------------------------------------
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
published by the Free Software Foundation.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

In addition, as a special exception, Boris Kolpackov gives permission
to combine this library with other incompatibly-licensed modules in a
single program and to distribute such a combination provided that there
is no use of the functionality implemented by this library, directly
or indirectly, by such modules. You must obey the GNU General Public
License version 2 in all respects for all of the code used other than
such modules. In particular, the resulting program must be licensed
under a license compatible with the GNU General Public License version
2. If you modify this copy of the library, you may extend this exception
to your version of the library, but you are not obligated to do so. If
you do not wish to do so, delete this exception statement from your
version.
-------------------------------------------------------------------

Let me know if you see any problems with this approach.
Comment 8 Mamoru TASAKA 2009-06-21 13:19:04 EDT
Well, I think changing the license to LGPLv2+ will do what
you want in more simple way.
Comment 9 Boris Kolpackov 2009-06-22 10:48:54 EDT
That would definitely be simpler. However, this involves two changes that I am not prepared to make at this time. Namely, the change from GPL to LGPL and the change from the specific, known version of the license to some future version which will have terms and conditions that I have no control over. So at the moment adding the above exception seems like the simplest way forward.
Comment 10 Mamoru TASAKA 2009-06-22 12:20:52 EDT
spot, would you judge if the license draft on comment 7
is sane for this package?
Comment 11 Mamoru TASAKA 2009-07-01 10:19:02 EDT
spot, would you tell us your opinion for the comment 7?
Comment 12 Tom "spot" Callaway 2009-07-01 10:59:38 EDT
The meat of this license looks fine, but Red Hat Legal pointed out that the copyright holder in xsd appears to be both Boris Kolpackov and Code Synthesis Tools. Therefore, please change the text that says "... Boris Kolpackov gives
permission ..." to something like " ... Boris Kolpackov and Code Synthesis
Tools CC give permission ..." to make sure we're covered in case Boris's
employer is the copyright holder of some or all of the GPL-licensed
code here. 

Once this is done, we should use this for the SPEC:

# Exceptions permit otherwise GPLv2 incompatible combination with ASL 2.0
License: GPLv2 with exceptions and ASL 2.0
Comment 13 Boris Kolpackov 2009-07-01 11:14:07 EDT
The xsd-3.2.0+dep package is actually the xsd compiler itself packaged with all its dependencies (there is also xsd-3.2.0 which is just the xsd compiler). Some of these dependencies are copyright Boris Kolpackov while the xsd compiler and the xsd-frontend library are copyright Code Synthesis Tools. The latter two (xsd and xsd-frontend) already include the exception that allows linking to Xerces-C++. It is the other packages (which are copyright Boris Kolpackov) that need the exception added. That's why the text uses "Boris Kolpackov" instead of "Boris Kolpackov & Code Synthesis Tools". Hope this clarifies things.
Comment 14 Tom "spot" Callaway 2009-07-01 11:52:47 EDT
Sure, that makes sense. 

Once the package is updated with the new license, I'll lift FE-Legal.
Comment 15 Boris Kolpackov 2009-07-01 23:18:42 EDT
I have released new versions of libcult, libfrontend-elements and libbackend-elements with the above license exception. I also uploaded a new version of the xsd-3.2.0+dep package which contains the new versions of the above libraries. Let me know if there is anything else you need from my side.
Comment 16 Antti Andreimann 2009-07-04 01:37:22 EDT
Updated tarball in SRPM as well as added license tag recommended in comment 12

Spec URL: http://anttix.org/fedora/pkg/xsd.spec
SRPM URL: http://anttix.org/fedora/pkg/xsd-3.2.0-2.fc10.src.rpm

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1453720
Comment 17 Tom "spot" Callaway 2009-07-05 18:50:31 EDT
Lifting FE-Legal.
Comment 18 Antti Andreimann 2009-07-06 12:01:48 EDT
Thanx!

Can somebody now mark the package as fedora-review+ ? :)

I have a question though: does it make sense to add to spec:

Provides: xsd-devel

For example syslinux (which contains headers and closely related binaries just like this package) does so.
Comment 19 Mamoru TASAKA 2009-07-06 12:04:33 EDT
For 3.2.0-2:

? ace
--------------------------------------------------------
# Requires:  ace-devel - only needed for applications using ACE streams
#                             enable when Fedora gets ACE packages
--------------------------------------------------------
  - Is this differect from
    https://admin.fedoraproject.org/pkgdb/packages/name/ace ?

* compiler flags
--------------------------------------------------------
    67  make: Entering directory `/builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult'
    68  m4 /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/cli/mapper.hxx.m4
    69  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/eh/exception.cxx
    70  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/mm/new.cxx
    71  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/mm/counter.cxx
    72  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/mm/buffer.cxx
    73  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/rtti/type-info.cxx
    74  c++ /builddir/build/BUILD/xsd-3.2.0+dep/libcult-1.4.4/cult/trace/log.cxx
--------------------------------------------------------
  - From this build.log it "seems" that Fedora specific compilation
    flags are not honored correctly:
    https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags

    Please make it sure that Fedora specific compilation flags are
    correctly honored. If this is already honored, make build.log more
    verbose so that we can easily check it from build.log.

! rpmlint warnings
---------------------------------------------------------
xsd-doc.i586: W: file-not-utf8 /usr/share/doc/xsd-doc-3.2.0/cxx/tree/guide/cxx-tree-guide.ps
xsd-doc.i586: W: file-not-utf8 /usr/share/doc/xsd-doc-3.2.0/cxx/parser/guide/cxx-parser-guide.ps
xsd-doc.i586: W: file-not-utf8 /usr/share/doc/xsd-doc-3.2.0/cxx/tree/manual/cxx-tree-manual.ps
---------------------------------------------------------
  - Can these files be converted into UTF-8 easily?
Comment 20 Mamoru TASAKA 2009-07-06 12:05:25 EDT
(In reply to comment #18)
> I have a question though: does it make sense to add to spec:
> Provides: xsd-devel

I don't think this is needed.
Comment 21 Antti Andreimann 2009-07-06 12:23:05 EDT
(In reply to comment #19)

> ? ace
> --------------------------------------------------------
> # Requires:  ace-devel - only needed for applications using ACE streams
> #                             enable when Fedora gets ACE packages
> --------------------------------------------------------
>   - Is this differect from
>     https://admin.fedoraproject.org/pkgdb/packages/name/ace ?

Yep!
The ace that XSD supports is an Adaptive Communication Environment
and can be found from here:
http://www.cs.wustl.edu/~schmidt/ACE.html

I'll add this URL as a comment to the spec file as a reminder what the hell
is ACE ;)

>     Please make it sure that Fedora specific compilation flags are
>     correctly honored. If this is already honored, make build.log more
>     verbose so that we can easily check it from build.log.

I'll look into it. Thanx.

> ---------------------------------------------------------
> xsd-doc.i586: W: file-not-utf8
> /usr/share/doc/xsd-doc-3.2.0/cxx/tree/guide/cxx-tree-guide.ps
> xsd-doc.i586: W: file-not-utf8
> /usr/share/doc/xsd-doc-3.2.0/cxx/parser/guide/cxx-parser-guide.ps
> xsd-doc.i586: W: file-not-utf8
> /usr/share/doc/xsd-doc-3.2.0/cxx/tree/manual/cxx-tree-manual.ps
> ---------------------------------------------------------
>   - Can these files be converted into UTF-8 easily?  

Unfortunately I'm not aware of a tool that can convert Postscript files to UTF-8. I tried to do it manually, but wasn't successful :(
I did however document this error in initial report.
Comment 22 Mamoru TASAKA 2009-07-06 12:45:41 EDT
(In reply to comment #21)
> (In reply to comment #19)
> 
> > ? ace
> > --------------------------------------------------------
> > # Requires:  ace-devel - only needed for applications using ACE streams
> > #                             enable when Fedora gets ACE packages
> > --------------------------------------------------------
> >   - Is this differect from
> >     https://admin.fedoraproject.org/pkgdb/packages/name/ace ?
> 
> Yep!
> The ace that XSD supports is an Adaptive Communication Environment
> and can be found from here:
> http://www.cs.wustl.edu/~schmidt/ACE.html

Ah, thanks. This one is review request bug 450164 (which
is blocked by legal issue)
Comment 23 Antti Andreimann 2009-07-06 13:08:12 EDT
(In reply to comment #19)

>     correctly honored. If this is already honored, make build.log more
>     verbose so that we can easily check it from build.log.

Build flags were already correctly honoured, the build log is now more verbose.

Updated package:
 %build
-CXXFLAGS=$RPM_OPT_FLAGS ./build.sh
+MAKEFLAGS="verbose=1" CXXFLAGS=$RPM_OPT_FLAGS ./build.sh

Also added new entries to changelog and a few comments.

Spec URL: http://anttix.org/fedora/pkg/xsd.spec
SRPM URL: http://anttix.org/fedora/pkg/xsd-3.2.0-3.fc10.src.rpm

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1457171
Comment 24 Mamoru TASAKA 2009-07-06 13:59:19 EDT
Okay.

----------------------------------------------------------------
    This package (xsd) is APPROVED by mtasaka
----------------------------------------------------------------
Comment 25 Antti Andreimann 2009-07-06 14:48:18 EDT
Thank You!

New Package CVS Request
=======================
Package Name: xsd
Short Description: W3C XML schema to C++ data binding compiler
Owners: anttix
Branches: F-10 F-11 EL-5
InitialCC:
Comment 26 Boris Kolpackov 2009-07-06 15:46:40 EDT
> Requires:  ace-devel

I don't think adding a requirement for ACE is a good idea. ACE support is optional and I would expect only a few people needing this functionality (binary serialization to ACE CDR streams). Is there something like Suggests: or Recommends: ?
Comment 27 Boris Kolpackov 2009-07-06 15:49:25 EDT
> Can these files be converted into UTF-8 easily?  

I think these files can be safely removed from the package. They are a by-product of creating the PDF files from XHTML and we only keep them because, well, we have them and maybe somebody would need them for something.
Comment 28 Antti Andreimann 2009-07-06 17:27:57 EDT
(In reply to comment #26)

> > Requires:  ace-devel
> 
> I don't think adding a requirement for ACE is a good idea. ACE support is
> optional and I would expect only a few people needing this functionality
> (binary serialization to ACE CDR streams). Is there something like Suggests: or
> Recommends: ?  

AFAIK there is no "recommended packages" information in RPM files.
The dependency is currently commented out because Fedora does not have ACE packages. If they become available, the decision whether to depend on them or not can be made. The current information in the spec file serves only as a reminder to me and other package maintainers to look into the issue when ACE packages become available.
Comment 29 Kevin Fenzi 2009-07-07 00:25:07 EDT
cvs done.
Comment 30 Fedora Update System 2009-07-07 12:30:54 EDT
xsd-3.2.0-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/xsd-3.2.0-4.fc11
Comment 31 Fedora Update System 2009-07-07 12:31:01 EDT
xsd-3.2.0-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/xsd-3.2.0-4.fc10
Comment 32 Mamoru TASAKA 2009-07-07 14:55:58 EDT
Now closing (it seems that on EL5 build fails due to gcc's ICE, however
anyway I close because on F-12/11/10 build succeeded)
Comment 33 Antti Andreimann 2009-07-07 16:31:20 EDT
Yeah! I am trying to get some meaningful debug information out of GCC to report a bug against EL-5.

The compiler bug shows up when -g switch is added to GCC command line.

So I have to ask: is it acceptable to remove -g from build flags as a temporary workaround so the package will build?

This will have the side-effect of killing xsd-debuginfo package.
Comment 34 Antti Andreimann 2009-07-07 18:46:23 EDT
EL5 has gcc43, but this one is unable to link ...

/usr/bin/ld: /builddir/build/BUILD/xsd-3.2.0+dep/xsd-3.2.0-2/xsd/xsd: hidden symbol `void std::__ostream_fill<char, std::char_traits<char> (std::basic_ostream<char, std::char_traits<char> >&, long)' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

The only way I can get it to build on EL5 is by filtering -g from
RPM_OPT_FLAGS :(
Comment 35 Boris Kolpackov 2009-07-07 19:33:45 EDT
> The compiler bug shows up when -g switch is added to GCC command line.

Yes, this a known problem with some earlier g++ 4.x versions. It is triggered when both optimization and debug information are requested (e.g., -O2 -g). Removing -g from the compilation flags should be harmless since it only affects the XSD compiler itself (i.e., there won't be any debug information in the compiler binary). Since the runtime library is header-only, the user applications that use the generated code won't be affected.
Comment 36 Antti Andreimann 2009-07-07 19:41:05 EDT
Well, I have now managed to get the package to link with gcc43 on EL5:

 %build
+CXX=g++43 LIBS=`$CXX -print-file-name=libstdc++.a` \
 MAKEFLAGS="verbose=1" CXXFLAGS=$RPM_OPT_FLAGS ./build.sh

$CXX -print-file-name=libstdc++.a evaluates to:
/usr/lib/gcc/i386-redhat-linux6E/4.3.2/libstdc++.a
which is part of a libstdc++43-devel package.

There is no corresponding libstdc++43 package.

This makes me nervous, since I'm not sure which parts of libstdc++ are now statically linked and which are still dynamic.
According to this blog post (http://www.trilithium.com/johan/2005/06/static-libstdc/), mixing statically and dynamically linked C++ code is not a very good idea.

Which would be the proper solution for EL5?
Filter -g and stick with GCC4.1 or compile with 4.3 and hope that this strange linking method actually works?
Comment 37 Boris Kolpackov 2009-07-07 20:57:36 EDT
I would suggest we filter -g out if this is acceptable. Your concern about linking to static libstdc++ is quite correct. There is another support library (libgcc_s) that is linked dynamically and the resulting executable will use the one from g++-4.1.
Comment 38 Alexander Boström 2009-07-08 01:44:58 EDT
The RHEL 5.4 beta announcement mentions "GCC 4.4". Maybe that'll help.
Comment 39 Kalev Lember 2009-07-08 03:24:22 EDT
The default debug information level is 2 when using -g switch. However, xsd seems to build fine with -g1, but with that we'd lose line numbers and local variable information when compared to full -g.

The following produces a -debuginfo package, but source files don't get included in it because of the -g1 switch used:

 %build
-MAKEFLAGS="verbose=1" CXXFLAGS=$RPM_OPT_FLAGS ./build.sh
+MAKEFLAGS="verbose=1" CXXFLAGS="$RPM_OPT_FLAGS -g1" ./build.sh
Comment 40 Mamoru TASAKA 2009-07-08 03:57:39 EDT
Would you contact gcc maintainer (i.e. file a bug report against
gcc) first?

Also for EL-5 build issue, please open a new bug ticket (against
xsd componet) and discuss there.
Comment 41 Fedora Update System 2009-07-16 02:55:57 EDT
xsd-3.2.0-4.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 42 Fedora Update System 2009-07-16 03:06:34 EDT
xsd-3.2.0-4.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.