From Brian.Cameron@sun.com Wed Jul 29 16:31:29 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6TNVTXt018838 for ; Wed, 29 Jul 2009 16:31:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6TNVS2q020248 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 29 Jul 2009 16:31:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNK00903HCG8H00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 29 Jul 2009 16:31:28 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNK00HLGHCFBM50@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 29 Jul 2009 16:31:27 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6TNVRW8028960 for ; Wed, 29 Jul 2009 23:31:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNK00500GQGOF00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 29 Jul 2009 17:31:27 -0600 (MDT) Received: from [129.153.250.102] ([unknown] [129.153.250.102]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNK00GK0HC5T7D0@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 29 Jul 2009 17:31:18 -0600 (MDT) Date: Wed, 29 Jul 2009 18:31:29 -0500 From: Brian Cameron Subject: Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] Sender: Brian.Cameron@sun.com To: LSARC-ext@sun.com Cc: Desktop Discuss Message-id: <4A70DBD1.2030901@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_FAoAIOyESJp2FkeUS+1Kgw)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090622) Status: RO Content-Length: 6838 This is a multi-part message in MIME format. --Boundary_(ID_FAoAIOyESJp2FkeUS+1Kgw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will timeout on August 12th. See attached onepager. Brian --Boundary_(ID_FAoAIOyESJp2FkeUS+1Kgw) Content-type: text/plain; name=onepage-raptor.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=onepage-raptor.txt Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Raptor 1.4.19 1.2. Name of Document Author/Supplier: Author: Jerry Tan Sponsor: Brian Cameron 1.3. Date of This Document: 07/21/09 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: robert.odea@sun.com 1.4.4. The name of your business unit: OpenSolaris Desktop 1.5. Email Aliases: 1.5.1. Responsible Manager: harry.lu@sun.com 1.5.2. Responsible Engineer: jerry.tan@sun.com 1.5.3. Marketing Manager: glynn.foster@sun.com 1.5.4. Interest List: desktop-discuss@opensolaris.org 2. Project Summary 2.1. Project Description: Raptor is a free software C library that provides a set of parsers and serializers that generate Resource Description Framework (RDF) triples by parsing syntaxes or serialize the triples into a syntax. 4. Technical Description: 4.1. Details: The Raptor library provides a high-level interface to a set of parsers and serializers that generate Resource Description Framework (RDF) triples by parsing syntaxes or serialize the triples into syntaxes. The supported parsing syntaxes include RDF/XML, N-Triples, Turtle, TRiG, RSS tag soup (including all RSS and Atoms), GRDDL, RDFa and the serializing syntaxes include RDF/XML (3 varieties), N-Triples, Turtle, RSS 1.0, Atom 1.0, GraphViz DOT and RDF/JSON. The RDF/XML parser can use libxml XML parsers for providing the SAX event stream. The library functions are arranged in an object-oriented style with constructors, destructors and method calls. The statements and error messages are delivered via callback functions. Raptor contains a URI-reference parsing and resolving (not retrieval) class (raptor_uri) sufficient for dealing with URI-references inside RDF. This functionality is modular and can be transparently replaced with another existing and compatible URI implementation. It also provides a URI-retrieval class (raptor_www) for wrapping existing library such as libxml2 or BSD libfetch that provides full or partial retrieval of data from URIs and an I/O stream abstraction (raptor_iostream) for supportin serializing to a variety of outputs. Raptor uses Unicode strings for RDF literals and URIs and preserves them throughout the library. It uses the UTF-8 encoding of Unicode at the API for passing in or returning Unicode strings. It is intended that the preservation of Unicode for URIs will support Internationalized Resource Identifiers (IRIs) which are still under development and standardisation. A typical C programe that use raptor may look like this #include raptor_init(); raptor_parser *p=raptor_new_parser("rdfxml"); raptor_set_statement_handler(p,NULL,print_triples); raptor_uri *file_uri=raptor_new_uri("http://example.org/"); raptor_parse_file(p,file_uri,base_uri); raptor_parse_uri(p,uri,NULL); raptor_free_parser(p); raptor_free_uri(file_uri); raptor_finish(); 4.2. Bug/RFE Number(s): 6859024 4.3. In Scope: See above. 4.4. Out of Scope: See above. 4.5. Interfaces: Exported Interface Interface Classification Comments ----------------------------- -------------- ---------------------- SUNWraptor Uncommitted Package name SUNWraptor-devel Uncommitted Package name /usr/bin/rapper Volatile parser utility /usr/bin/raptor-config Volatile config utility /usr/lib/libraptor.so.1 Volatile library /usr/share/man/man1/rapper.1 Volatile man page /usr/share/man/man1/raptor-config.1 Volatile man page /usr/share/man/man3/libraptor.3 Volatile man page /usr/lib/pkgconfig/raptor.pc Volatile pc file /usr/include/raptor.h Volatile Header file /usr/share/gtk-doc/html/raptor Volatile help file Imported Interface Interface Classification ARC case Comment -------- --------------- ---------- ------------------------------- XSLT Uncommitted PSARC/2002/244 XML2 Committed PSARC/2008/032 4.6. Doc Impact: Help docs and man page 4.7. Admin/Config Impact: None. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: The OpenSolaris Desktop team and the G11N are working together to evaluate and provide I18N/L10N support. 4.10. Packaging & Delivery: Adds two new packages: Package Cluster Comment ------------------ ------------ ---------- SUNWraptor SUNW(gnapps) base package for libraries SUNWraptor-devel SUNW(gnapps) dev pkg for raptor 4.11. Security Impact: None 4.12. Dependencies: Refer to Imported Interface table. 5. Reference Documents: [1] RDF http://www.w3.org/TR/rdf-concepts/ http://www.w3.org/TR/rdf-syntax-grammar/ http://www.w3.org/2001/sw/RDFCore/ http://www.w3.org/TR/rdf-testcases/#ntriples http://www.dajobe.org/2004/01/turtle/ [2] raptor homepage: http://librdf.org/raptor/ [3] Related ARC Cases: PSARC/2002/244 Using XSLT and libxslt in Solaris PSARC/2008/032 libxml2 upgrade to 2.6.31 PSARC/2001/175 Using XML and libxml in Solaris --Boundary_(ID_FAoAIOyESJp2FkeUS+1Kgw)-- From oboril.lukas@gmail.com Thu Jul 30 01:03:39 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6U83cR7004560 for ; Thu, 30 Jul 2009 01:03:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6U83Z0b044585; Thu, 30 Jul 2009 02:03:38 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNL0050T521G300@brm-avmta-1.central.sun.com>; Thu, 30 Jul 2009 02:03:37 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNL00KFT51ZVF50@brm-avmta-1.central.sun.com>; Thu, 30 Jul 2009 02:03:35 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6U7xW6X029534; Thu, 30 Jul 2009 08:03:35 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-1363987; Thu, 30 Jul 2009 08:03:35 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-28506769; Thu, 30 Jul 2009 08:03:31 +0000 (Z) Received: from mail-bw0-f211.google.com ([209.85.218.211] [209.85.218.211]) by relay4i.sun.com with ESMTP id BT-MMP-5414587; Thu, 30 Jul 2009 08:03:31 +0000 (Z) Received: by mail-bw0-f211.google.com with SMTP id 7so1166713bwz.8 for ; Thu, 30 Jul 2009 01:03:25 -0700 (PDT) Received: by 10.223.115.193 with SMTP id j1mr389907faq.98.1248941005447; Thu, 30 Jul 2009 01:03:25 -0700 (PDT) Date: Thu, 30 Jul 2009 10:02:05 +0200 From: Lukas Oboril Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A70DBD1.2030901@sun.com> To: Brian Cameron Cc: LSARC-ext@sun.com, Desktop Discuss Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=WEHG4cweFDY+ZBphg0MwBUNkuUjKAt7naqwWNr67Yg4=; b=Tenqc/8ioypsw2jAlQl9/7Tlnjqp+d6oOx1aJLZvc62DBsAWKXdG+8MFMVz9YXr830 r2hvx5jLCuPk6GzrmvoH3AH53XupgUS2S0fmpolhKt22c3qZkLwVgitLvuYNuRfaAX9N 1mJNUlfP21A4iyqIK/RmYNuVmAM9FWCG8cVtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=hA6mKvyOmPeh0C6hf4exvOOx79KoIa+cumPr0T9LWqQjNMTf71G4cdvF55hgBT3+eR 4lUWP6uXPc8QNDkVyerSwobchqR8gm3DCfq32KeMmwIfIU0eQ+91FYxqcwNaGvzGUhqG ZZ6zymrIMOw0D+fTS+IbPoskofZ0j12ksDEgU= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 3.301sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A70DBD1.2030901@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n6U83cR7004560 Status: RO Content-Length: 7170 Brian, I do not see 64bit version of library. Luc On Thu, Jul 30, 2009 at 1:31 AM, Brian Cameron wrote: > > I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will > timeout on August 12th.  See attached onepager. > > Brian > > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2007 Sun Microsystems > > 1. Introduction >   1.1. Project/Component Working Name: > >        Raptor  1.4.19 > >   1.2. Name of Document Author/Supplier: > >        Author:  Jerry Tan >        Sponsor: Brian Cameron > >   1.3. Date of This Document: > >        07/21/09 > >   1.4. Name of Major Document Customer(s)/Consumer(s): > >      1.4.1. The PAC or CPT you expect to review your project: > >             Solaris PAC > >      1.4.2. The ARC(s) you expect to review your project: > >             LSARC > >      1.4.3. The Director/VP who is "Sponsoring" this project: > >             robert.odea@sun.com > >      1.4.4. The name of your business unit: > >             OpenSolaris Desktop > >   1.5. Email Aliases: > >      1.5.1. Responsible Manager: > >             harry.lu@sun.com > >      1.5.2. Responsible Engineer: > >             jerry.tan@sun.com > >      1.5.3. Marketing Manager: > >             glynn.foster@sun.com > >      1.5.4. Interest List: > >             desktop-discuss@opensolaris.org > > 2. Project Summary > >   2.1. Project Description: > >        Raptor is a free software C library that provides a set of parsers >  and >        serializers that generate Resource Description Framework (RDF) >  triples >        by parsing syntaxes or serialize the triples into a syntax. > > 4. Technical Description: > >    4.1. Details: > >        The Raptor library provides a high-level interface to a set of > parsers >        and serializers that generate Resource Description Framework (RDF) >        triples by parsing syntaxes or serialize the triples into syntaxes. > >        The supported parsing syntaxes include RDF/XML, N-Triples, Turtle, > TRiG, >        RSS tag soup  (including all RSS and Atoms), GRDDL, RDFa and the >        serializing syntaxes include RDF/XML (3 varieties), N-Triples, > Turtle, >        RSS 1.0, Atom 1.0, GraphViz DOT and RDF/JSON. The RDF/XML parser can >        use libxml XML parsers  for providing the SAX event stream. The > library >        functions are arranged in an object-oriented style with constructors, >        destructors and method  calls. The statements and error messages are >        delivered via callback functions. > >        Raptor contains a URI-reference parsing and resolving (not retrieval) >        class (raptor_uri)  sufficient for dealing with URI-references inside >        RDF.  This functionality is modular and can be transparently replaced >        with another existing and compatible URI implementation. > >        It also provides a URI-retrieval class (raptor_www) for wrapping >        existing  library such as libxml2 or BSD libfetch that provides full >        or partial retrieval of data from URIs and an I/O stream abstraction >        (raptor_iostream) for supportin serializing to a variety of outputs. > >        Raptor uses Unicode strings for RDF literals and URIs and preserves >        them throughout the library. It uses the UTF-8 encoding of Unicode >        at the API for passing in or returning Unicode strings. It is > intended >        that the preservation of Unicode for URIs will support > Internationalized >        Resource Identifiers (IRIs) which are still under development >        and standardisation. > >        A typical C programe that use raptor may look like this > >        #include > >        raptor_init(); >        raptor_parser *p=raptor_new_parser("rdfxml"); >        raptor_set_statement_handler(p,NULL,print_triples); >        raptor_uri *file_uri=raptor_new_uri("http://example.org/"); >        raptor_parse_file(p,file_uri,base_uri); >        raptor_parse_uri(p,uri,NULL); >        raptor_free_parser(p); >        raptor_free_uri(file_uri); >        raptor_finish(); > > >    4.2. Bug/RFE Number(s): > >         6859024 > >    4.3. In Scope: > >         See above. > >    4.4. Out of Scope: > >         See above. > >    4.5. Interfaces: > >         Exported  Interface > >    Interface                          Classification         Comments >    -----------------------------     --------------  ---------------------- >    SUNWraptor                        Uncommitted     Package name >    SUNWraptor-devel                  Uncommitted     Package name >    /usr/bin/rapper                   Volatile        parser utility >    /usr/bin/raptor-config            Volatile        config utility >    /usr/lib/libraptor.so.1           Volatile        library >    /usr/share/man/man1/rapper.1      Volatile        man page >    /usr/share/man/man1/raptor-config.1 >                                      Volatile        man page >    /usr/share/man/man3/libraptor.3   Volatile        man page >    /usr/lib/pkgconfig/raptor.pc      Volatile        pc file >    /usr/include/raptor.h             Volatile        Header file >    /usr/share/gtk-doc/html/raptor    Volatile        help file > >          Imported  Interface > >    Interface  Classification    ARC case  Comment >    --------   --------------- ---------- ------------------------------- >    XSLT       Uncommitted       PSARC/2002/244 >    XML2       Committed         PSARC/2008/032 > > >    4.6. Doc Impact: > >         Help docs and man page > >    4.7. Admin/Config Impact: > >         None. > >    4.8. HA Impact: > >         None. > >    4.9. I18N/L10N Impact: > >         The OpenSolaris Desktop team and the G11N are working together to >         evaluate and  provide I18N/L10N support. > >    4.10. Packaging & Delivery: > >          Adds two new packages: >          Package               Cluster                  Comment >          ------------------     ------------   ---------- >          SUNWraptor             SUNW(gnapps)   base package for libraries >          SUNWraptor-devel       SUNW(gnapps)   dev pkg for raptor > >    4.11. Security Impact: > >          None > >    4.12. Dependencies: > >          Refer to Imported Interface table. > > > 5. Reference Documents: > >     [1] RDF >         http://www.w3.org/TR/rdf-concepts/ >         http://www.w3.org/TR/rdf-syntax-grammar/ >         http://www.w3.org/2001/sw/RDFCore/ >         http://www.w3.org/TR/rdf-testcases/#ntriples >         http://www.dajobe.org/2004/01/turtle/ > >     [2] raptor homepage: >         http://librdf.org/raptor/ > >     [3] Related ARC Cases: > >         PSARC/2002/244  Using XSLT and libxslt in Solaris >         PSARC/2008/032  libxml2 upgrade to 2.6.31 >         PSARC/2001/175  Using XML and libxml in Solaris > > > _______________________________________________ > desktop-discuss mailing list > desktop-discuss@opensolaris.org > -- Lukas 'Luc' Oboril IRC nickname: luc^ at freenode When dealing with people, let us remember we are not dealing with creatures of logic. We are dealing with creatures of emotions, creatures bristling with prejudices and motivated by pride and vanity. Dale Carnegie From storycrafter@gmail.com Thu Jul 30 10:53:31 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6UHrU2c020369 for ; Thu, 30 Jul 2009 10:53:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6UHrOUd014433; Fri, 31 Jul 2009 01:53:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNL00K03WD11O00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 30 Jul 2009 10:53:25 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNL00JBJWD1XIE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 30 Jul 2009 10:53:25 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6UHhFcI007162; Thu, 30 Jul 2009 17:53:25 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay41i.sun.com with ESMTP id BT-MMP-1391486; Thu, 30 Jul 2009 17:53:25 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-29511381; Thu, 30 Jul 2009 17:53:24 +0000 (Z) Received: from mail-px0-f200.google.com ([209.85.216.200] [209.85.216.200]) by relay4i.sun.com with ESMTP id BT-MMP-6499325; Thu, 30 Jul 2009 17:53:23 +0000 (Z) Received: by pxi38 with SMTP id 38so491728pxi.30 for ; Thu, 30 Jul 2009 10:52:39 -0700 (PDT) Received: by 10.140.201.8 with SMTP id y8mr1168160rvf.45.1248976359631; Thu, 30 Jul 2009 10:52:39 -0700 (PDT) Received: from ?172.16.202.89? (68-252-106-20.ded.ameritech.net [68.252.106.20]) by mx.google.com with ESMTPS id l31sm13306637rvb.54.2009.07.30.10.52.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 10:52:38 -0700 (PDT) Date: Thu, 30 Jul 2009 12:52:36 -0500 From: Mark Martin Subject: Re: Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A70DBD1.2030901@sun.com> To: Brian Cameron Cc: LSARC-ext@sun.com, Desktop Discuss Message-id: <4A71DDE4.9030704@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Mfz+wlpAwc74c+2fLWMTnZ7K44wguAcurjv5vQInxzY=; b=LeeQDG1lPYOlaDyVEm+ac2RH8JTiFAvNn+cano0U4MdWo18Y6UzyXCiW7KyRT6faQd lhnmaubn3q3Xv2XWrTBrJvKYewAIQqt7BBzIxkuWBsrGK1/hSK30GK+iltccfDvtFHZO T5CnjYuNNpvDmSMOS8lWobmSxcCip/0KE9Zjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=UgO2H7ivbJ3fDVL5dZxFmj0jSeALRTP5utZA2FH6YPsvbRatKWIPuu+Plj2IIgsvJr UBtl4bLDkyvY35EYudOJ8hpNIHlC1P3shUpfszsBzZ0wATuKbT/fpRz1ANbjNM7erajK zAdChc+3PWgTHWpu7vAgNr4VRlcFL5gIx4xuU= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 0.069sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A70DBD1.2030901@sun.com> User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Status: RO Content-Length: 2414 Brian Cameron wrote: > > I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will > timeout on August 12th. See attached onepager. > > Brian <...excerpted from the attachment...> > 4.5. Interfaces: > > Exported Interface > > Interface Classification Comments > ----------------------------- -------------- ---------------------- > SUNWraptor Uncommitted Package name > SUNWraptor-devel Uncommitted Package name > /usr/bin/rapper Volatile parser utility > /usr/bin/raptor-config Volatile config utility > /usr/lib/libraptor.so.1 Volatile library > /usr/share/man/man1/rapper.1 Volatile man page > /usr/share/man/man1/raptor-config.1 > Volatile man page > /usr/share/man/man3/libraptor.3 Volatile man page > /usr/lib/pkgconfig/raptor.pc Volatile pc file > /usr/include/raptor.h Volatile Header file > /usr/share/gtk-doc/html/raptor Volatile help file I notice that most of the exported interfaces are "Volatile". This seems low, especially since the upstream itself seems committed to stability (e.g. the notice regarding the ABI/API change on the front page). Isn't "Uncommitted" more appropriate? Also, is this *library* racing another FOSS product -- i.e. will we see another consuming application show up soon? I ask merely out of curiosity -- I believe we have a pattern of delivering (FOSS enabling) libraries in LSARC, whereas PSARC often challenges libraries without consumers. And this seems like such a specialized library. . . Also, another point of personal clarification -- I notice not all projects complete a FOSS checklist. This one didn't seem to. I suspect that's fine, except that in this particular case, I couldn't find a binding level. I notice that's an explicit question in the FOSS checklist, but reviewing many recent one-pagers reveals that this detail is very often omitted. What is the binding level here? One final nit -- are we really interested in delivering raptor.pc? It's not really been common practice up until now to deliver those ./configure artifacts. Other than these nits, the case looks fine to me. From Brian.Cameron@sun.com Thu Jul 30 12:18:04 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6UJI47h026361 for ; Thu, 30 Jul 2009 12:18:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6UJI3OF003488 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 30 Jul 2009 12:18:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNM00D0B0A30X00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 30 Jul 2009 12:18:03 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNM004TN0A23M50@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 30 Jul 2009 12:18:02 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6UJI1ME003925 for ; Thu, 30 Jul 2009 19:18:01 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNM0080004R9J00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 30 Jul 2009 13:18:01 -0600 (MDT) Received: from [129.153.250.170] ([unknown] [129.153.250.170]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNM00FX109ZN6C0@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 30 Jul 2009 13:17:59 -0600 (MDT) Date: Thu, 30 Jul 2009 14:18:10 -0500 From: Brian Cameron Subject: Re: Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A71DDE4.9030704@gmail.com> Sender: Brian.Cameron@sun.com To: Mark Martin Cc: LSARC-ext@sun.com, Desktop Discuss , jerry tan Message-id: <4A71F1F2.9070002@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090622) Status: RO Content-Length: 3016 Mark: > Brian Cameron wrote: >> >> I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will >> timeout on August 12th. See attached onepager. >> >> Brian > <...excerpted from the attachment...> >> 4.5. Interfaces: >> Exported Interface >> Interface Classification Comments >> ----------------------------- -------------- >> ---------------------- >> SUNWraptor Uncommitted Package name >> SUNWraptor-devel Uncommitted Package name >> /usr/bin/rapper Volatile parser utility >> /usr/bin/raptor-config Volatile config utility >> /usr/lib/libraptor.so.1 Volatile library >> /usr/share/man/man1/rapper.1 Volatile man page >> /usr/share/man/man1/raptor-config.1 >> Volatile man page >> /usr/share/man/man3/libraptor.3 Volatile man page >> /usr/lib/pkgconfig/raptor.pc Volatile pc file >> /usr/include/raptor.h Volatile Header file >> /usr/share/gtk-doc/html/raptor Volatile help file > I notice that most of the exported interfaces are "Volatile". This > seems low, especially since the upstream itself seems committed to > stability (e.g. the notice regarding the ABI/API change on the front > page). Isn't "Uncommitted" more appropriate? I will leave this question for Jerry to answer. > Also, is this *library* racing another FOSS product -- i.e. will we see > another consuming application show up soon? I ask merely out of > curiosity -- I believe we have a pattern of delivering (FOSS enabling) > libraries in LSARC, whereas PSARC often challenges libraries without > consumers. And this seems like such a specialized library. . . My understanding is that this library will be used in the next release of Tracker that we ship, thus the need to integrate it. > Also, another point of personal clarification -- I notice not all > projects complete a FOSS checklist. This one didn't seem to. I suspect > that's fine, except that in this particular case, I couldn't find a > binding level. I notice that's an explicit question in the FOSS > checklist, but reviewing many recent one-pagers reveals that this detail > is very often omitted. What is the binding level here? This case is intended to be included only in future releases of Nevada, so a minor release binding. > One final nit -- are we really interested in delivering raptor.pc? > It's not really been common practice up until now to deliver those > ./configure artifacts. The pc file is not a configure artifact, it is an input file into pkg-config. If you look in the /usr/lib/pkgconfig directory, you will notice that most free/open source modules provide pc files so that other modules can identify if the dependency is on the system, what version is installed, etc. Brian From Jerry.Tan@sun.com Thu Jul 30 19:30:43 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6V2UgeF010413 for ; Thu, 30 Jul 2009 19:30:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6V2Uafj009775 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 31 Jul 2009 03:30:42 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNM00503KB5OY00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 30 Jul 2009 20:30:41 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNM00LXKKB3HKB0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 30 Jul 2009 20:30:40 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6V2UdGO027262 for ; Fri, 31 Jul 2009 02:30:39 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNM00I00K4Z5B00@mail-apac.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:30:39 +0800 (SGT) Received: from [129.158.217.235] ([unknown] [129.158.217.235]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNM00K30KB2ZNH0@mail-apac.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:30:39 +0800 (SGT) Date: Fri, 31 Jul 2009 10:30:56 +0800 From: Jerry Tan Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: Sender: Jerry.Tan@sun.com To: Lukas Oboril Cc: Brian Cameron , LSARC-ext@sun.com, Desktop Discuss Message-id: <4A725760.5010102@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 7406 Hi, Lukas, because the only application that use raptor is tracker new version, it is a 32bit application. so we don't build 64bit binary for raptor. If we got a request that some 64bit application use it, we will release 64bit library for it. thanks. > Brian, > > I do not see 64bit version of library. > > > Luc > > On Thu, Jul 30, 2009 at 1:31 AM, Brian Cameron wrote: > >> I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will >> timeout on August 12th. See attached onepager. >> >> Brian >> >> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >> Copyright 2007 Sun Microsystems >> >> 1. Introduction >> 1.1. Project/Component Working Name: >> >> Raptor 1.4.19 >> >> 1.2. Name of Document Author/Supplier: >> >> Author: Jerry Tan >> Sponsor: Brian Cameron >> >> 1.3. Date of This Document: >> >> 07/21/09 >> >> 1.4. Name of Major Document Customer(s)/Consumer(s): >> >> 1.4.1. The PAC or CPT you expect to review your project: >> >> Solaris PAC >> >> 1.4.2. The ARC(s) you expect to review your project: >> >> LSARC >> >> 1.4.3. The Director/VP who is "Sponsoring" this project: >> >> robert.odea@sun.com >> >> 1.4.4. The name of your business unit: >> >> OpenSolaris Desktop >> >> 1.5. Email Aliases: >> >> 1.5.1. Responsible Manager: >> >> harry.lu@sun.com >> >> 1.5.2. Responsible Engineer: >> >> jerry.tan@sun.com >> >> 1.5.3. Marketing Manager: >> >> glynn.foster@sun.com >> >> 1.5.4. Interest List: >> >> desktop-discuss@opensolaris.org >> >> 2. Project Summary >> >> 2.1. Project Description: >> >> Raptor is a free software C library that provides a set of parsers >> and >> serializers that generate Resource Description Framework (RDF) >> triples >> by parsing syntaxes or serialize the triples into a syntax. >> >> 4. Technical Description: >> >> 4.1. Details: >> >> The Raptor library provides a high-level interface to a set of >> parsers >> and serializers that generate Resource Description Framework (RDF) >> triples by parsing syntaxes or serialize the triples into syntaxes. >> >> The supported parsing syntaxes include RDF/XML, N-Triples, Turtle, >> TRiG, >> RSS tag soup (including all RSS and Atoms), GRDDL, RDFa and the >> serializing syntaxes include RDF/XML (3 varieties), N-Triples, >> Turtle, >> RSS 1.0, Atom 1.0, GraphViz DOT and RDF/JSON. The RDF/XML parser can >> use libxml XML parsers for providing the SAX event stream. The >> library >> functions are arranged in an object-oriented style with constructors, >> destructors and method calls. The statements and error messages are >> delivered via callback functions. >> >> Raptor contains a URI-reference parsing and resolving (not retrieval) >> class (raptor_uri) sufficient for dealing with URI-references inside >> RDF. This functionality is modular and can be transparently replaced >> with another existing and compatible URI implementation. >> >> It also provides a URI-retrieval class (raptor_www) for wrapping >> existing library such as libxml2 or BSD libfetch that provides full >> or partial retrieval of data from URIs and an I/O stream abstraction >> (raptor_iostream) for supportin serializing to a variety of outputs. >> >> Raptor uses Unicode strings for RDF literals and URIs and preserves >> them throughout the library. It uses the UTF-8 encoding of Unicode >> at the API for passing in or returning Unicode strings. It is >> intended >> that the preservation of Unicode for URIs will support >> Internationalized >> Resource Identifiers (IRIs) which are still under development >> and standardisation. >> >> A typical C programe that use raptor may look like this >> >> #include >> >> raptor_init(); >> raptor_parser *p=raptor_new_parser("rdfxml"); >> raptor_set_statement_handler(p,NULL,print_triples); >> raptor_uri *file_uri=raptor_new_uri("http://example.org/"); >> raptor_parse_file(p,file_uri,base_uri); >> raptor_parse_uri(p,uri,NULL); >> raptor_free_parser(p); >> raptor_free_uri(file_uri); >> raptor_finish(); >> >> >> 4.2. Bug/RFE Number(s): >> >> 6859024 >> >> 4.3. In Scope: >> >> See above. >> >> 4.4. Out of Scope: >> >> See above. >> >> 4.5. Interfaces: >> >> Exported Interface >> >> Interface Classification Comments >> ----------------------------- -------------- ---------------------- >> SUNWraptor Uncommitted Package name >> SUNWraptor-devel Uncommitted Package name >> /usr/bin/rapper Volatile parser utility >> /usr/bin/raptor-config Volatile config utility >> /usr/lib/libraptor.so.1 Volatile library >> /usr/share/man/man1/rapper.1 Volatile man page >> /usr/share/man/man1/raptor-config.1 >> Volatile man page >> /usr/share/man/man3/libraptor.3 Volatile man page >> /usr/lib/pkgconfig/raptor.pc Volatile pc file >> /usr/include/raptor.h Volatile Header file >> /usr/share/gtk-doc/html/raptor Volatile help file >> >> Imported Interface >> >> Interface Classification ARC case Comment >> -------- --------------- ---------- ------------------------------- >> XSLT Uncommitted PSARC/2002/244 >> XML2 Committed PSARC/2008/032 >> >> >> 4.6. Doc Impact: >> >> Help docs and man page >> >> 4.7. Admin/Config Impact: >> >> None. >> >> 4.8. HA Impact: >> >> None. >> >> 4.9. I18N/L10N Impact: >> >> The OpenSolaris Desktop team and the G11N are working together to >> evaluate and provide I18N/L10N support. >> >> 4.10. Packaging & Delivery: >> >> Adds two new packages: >> Package Cluster Comment >> ------------------ ------------ ---------- >> SUNWraptor SUNW(gnapps) base package for libraries >> SUNWraptor-devel SUNW(gnapps) dev pkg for raptor >> >> 4.11. Security Impact: >> >> None >> >> 4.12. Dependencies: >> >> Refer to Imported Interface table. >> >> >> 5. Reference Documents: >> >> [1] RDF >> http://www.w3.org/TR/rdf-concepts/ >> http://www.w3.org/TR/rdf-syntax-grammar/ >> http://www.w3.org/2001/sw/RDFCore/ >> http://www.w3.org/TR/rdf-testcases/#ntriples >> http://www.dajobe.org/2004/01/turtle/ >> >> [2] raptor homepage: >> http://librdf.org/raptor/ >> >> [3] Related ARC Cases: >> >> PSARC/2002/244 Using XSLT and libxslt in Solaris >> PSARC/2008/032 libxml2 upgrade to 2.6.31 >> PSARC/2001/175 Using XML and libxml in Solaris >> >> >> _______________________________________________ >> desktop-discuss mailing list >> desktop-discuss@opensolaris.org >> >> > > > > From Jerry.Tan@sun.com Thu Jul 30 20:12:04 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6V3C3SD020808 for ; Thu, 30 Jul 2009 20:12:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6V3BdYe029015 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 31 Jul 2009 11:12:02 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNM00109M800S00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 30 Jul 2009 20:12:00 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNM00LCSM7NOHB0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 30 Jul 2009 20:11:59 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6V3BkBE014678 for ; Fri, 31 Jul 2009 03:11:46 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNM00C00M7JTC00@mail-apac.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 11:11:46 +0800 (SGT) Received: from [129.158.217.235] ([unknown] [129.158.217.235]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNM002PYM7LFJ00@mail-apac.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 11:11:46 +0800 (SGT) Date: Fri, 31 Jul 2009 11:12:03 +0800 From: Jerry Tan Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A71DDE4.9030704@gmail.com> Sender: Jerry.Tan@sun.com To: Mark Martin Cc: Brian Cameron , LSARC-ext@sun.com, Desktop Discuss Message-id: <4A726103.6010001@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 3667 Hi, Mark. please see my comments inline. thanks. Mark Martin : > Brian Cameron wrote: >> >> I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will >> timeout on August 12th. See attached onepager. >> >> Brian > <...excerpted from the attachment...> >> 4.5. Interfaces: >> Exported Interface >> Interface Classification Comments >> ----------------------------- -------------- >> ---------------------- >> SUNWraptor Uncommitted Package name >> SUNWraptor-devel Uncommitted Package name >> /usr/bin/rapper Volatile parser utility >> /usr/bin/raptor-config Volatile config utility >> /usr/lib/libraptor.so.1 Volatile library >> /usr/share/man/man1/rapper.1 Volatile man page >> /usr/share/man/man1/raptor-config.1 >> Volatile man page >> /usr/share/man/man3/libraptor.3 Volatile man page >> /usr/lib/pkgconfig/raptor.pc Volatile pc file >> /usr/include/raptor.h Volatile Header file >> /usr/share/gtk-doc/html/raptor Volatile help file > I notice that most of the exported interfaces are "Volatile". This > seems low, especially since the upstream itself seems committed to > stability (e.g. the notice regarding the ABI/API change on the front > page). Isn't "Uncommitted" more appropriate? From its release note and changelog, http://librdf.org/raptor/RELEASE.html#rel1_4_19 "New development will move to raptor 2 where a planned ABI and API break will happen" So I would rather call it as "Volatile". > > Also, is this *library* racing another FOSS product -- i.e. will we > see another consuming application show up soon? I ask merely out of > curiosity -- I believe we have a pattern of delivering (FOSS enabling) > libraries in LSARC, whereas PSARC often challenges libraries without > consumers. And this seems like such a specialized library. . . Tracker, one desktop search tool, see LSARC/2008/375/ its new version (maybe 0.7.0) is depending on libraptor. the release date is not fixed, but hopefully it will be released by the end of this year. so I made this ARC case to integrate its new dependency. > > Also, another point of personal clarification -- I notice not all > projects complete a FOSS checklist. This one didn't seem to. I > suspect that's fine, except that in this particular case, I couldn't > find a binding level. I notice that's an explicit question in the > FOSS checklist, but reviewing many recent one-pagers reveals that this > detail is very often omitted. What is the binding level here? > From FOSS checklist Document " After the check list is completed the project team should be able to determine if a project can be automatically approved. This will occur if all checks result in no "ARC review required" answers. " This ARC case is made by my team to request ARC review, so we did not complete a FOSS checklist. we plan to integrate raptor 1.4.19 into NV. > One final nit -- are we really interested in delivering raptor.pc? > It's not really been common practice up until now to deliver those > ./configure artifacts. raptor.pc is needed. In fact,a library bundled one pc file is recommended, since pkg-config can use it to get CFLAGS, LIB flags. and pkg-config is used very often. IMO, raptor-confg , which can be used to get CFLAGS and LIBS , will be removed in its future version. since release a pc file is more common. From James.Walker@sun.com Fri Jul 31 00:43:04 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6V7h40S022957 for ; Fri, 31 Jul 2009 00:43:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6V7h3rb019051 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 31 Jul 2009 00:43:04 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNM00H19YRRIL00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 01:43:03 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNM007J7YRRJQC0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 01:43:03 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6V7h39L004429 for ; Fri, 31 Jul 2009 07:43:03 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNM00A00YC5XR00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 01:43:03 -0600 (MDT) Received: from c-67-177-238-245.hsd1.co.comcast.net ([unknown] [129.150.32.36]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNM003SFYRR5GD0@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 01:43:03 -0600 (MDT) Date: Fri, 31 Jul 2009 01:43:03 -0600 From: Jim Walker Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: Sender: James.Walker@sun.com To: Brian Cameron Cc: LSARC-ext@sun.com, Desktop Discuss Reply-to: James.Walker@sun.com Message-id: <4A72A087.6010103@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) Status: RO Content-Length: 2457 >> 4.5. Interfaces: >> >> Exported Interface >> >> Interface Classification Comments >> ----------------------------- -------------- ---------------------- >> SUNWraptor Uncommitted Package name >> SUNWraptor-devel Uncommitted Package name >> /usr/bin/rapper Volatile parser utility >> /usr/bin/raptor-config Volatile config utility >> /usr/lib/libraptor.so.1 Volatile library >> /usr/share/man/man1/rapper.1 Volatile man page >> /usr/share/man/man1/raptor-config.1 >> Volatile man page >> /usr/share/man/man3/libraptor.3 Volatile man page >> /usr/lib/pkgconfig/raptor.pc Volatile pc file >> /usr/include/raptor.h Volatile Header file >> /usr/share/gtk-doc/html/raptor Volatile help file Some comments: 1. Man pages aren't interfaces and shouldn't be included here. 2. Documentation isn't an interface and shouldn't be include here. 3. Individual include files don't need to be specified. 4. Package classifications should match interface classifications. 5. Library symlink should be provided. Here's what I end up with: Interface Classification Comments ----------------------------- -------------- ------------------ SUNWraptor Volatile Package name SUNWraptor-devel Volatile Package name /usr/bin/rapper Volatile parser utility /usr/bin/raptor-config Volatile config utility /usr/lib/libraptor.so Volatile library symlink /usr/lib/libraptor.so.1 Volatile library /usr/lib/pkgconfig/raptor.pc Volatile pc file /usr/include/ Volatile Header files Also, it would be good for the desktop community to evaluate the current strategy of only delivering 64bit libraries as needed. It's normally easier for engineers to produce both archs at the time of initial putback then later, and we are seeing more and more interest in community members wanting to produce 64bit ready desktops. Because of this, "as needed" strategy it creates a barrier. If you are concerned about space, you could include the 64bit libraries only in the devel packages for now. Cheers, Jim From Jan.Hnatek@Sun.COM Fri Jul 31 00:48:59 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6V7mxcM023005 for ; Fri, 31 Jul 2009 00:48:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6V7mwjI021013 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 31 Jul 2009 00:48:59 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNM00K05Z1MZH00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 00:48:58 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNM00571Z1LKKD0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 00:48:57 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6V7muCr023100 for ; Fri, 31 Jul 2009 07:48:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNM00700YG4LG00@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 08:48:54 +0100 (BST) Received: from [10.0.0.103] ([unknown] [193.86.129.137]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNM00CIDZ1CWY30@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 08:48:49 +0100 (BST) Date: Fri, 31 Jul 2009 09:48:47 +0200 From: Jan Hnatek Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A725760.5010102@sun.com> Sender: Jan.Hnatek@Sun.COM To: Jerry Tan Cc: Lukas Oboril , Brian Cameron , LSARC-ext@Sun.COM, Desktop Discuss Message-id: <4A72A1DF.10302@sun.com> Organization: SUN Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A725760.5010102@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 8055 Hi Jerry, please include the 64bit libraries too. For example the redland and soprano libraries in the KDE project depend on raptor and it would be impossible/problematic to switch to using system-delivered raptor libraries. Regards, hnhn Jerry Tan wrote: > > Hi, Lukas, > > because the only application that use raptor is tracker new version, > it is a 32bit application. > so we don't build 64bit binary for raptor. > > If we got a request that some 64bit application use it, > we will release 64bit library for it. > > thanks. > > >> Brian, >> >> I do not see 64bit version of library. >> >> >> Luc >> >> On Thu, Jul 30, 2009 at 1:31 AM, Brian Cameron >> wrote: >> >>> I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will >>> timeout on August 12th. See attached onepager. >>> >>> Brian >>> >>> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >>> Copyright 2007 Sun Microsystems >>> >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> >>> Raptor 1.4.19 >>> >>> 1.2. Name of Document Author/Supplier: >>> >>> Author: Jerry Tan >>> Sponsor: Brian Cameron >>> >>> 1.3. Date of This Document: >>> >>> 07/21/09 >>> >>> 1.4. Name of Major Document Customer(s)/Consumer(s): >>> >>> 1.4.1. The PAC or CPT you expect to review your project: >>> >>> Solaris PAC >>> >>> 1.4.2. The ARC(s) you expect to review your project: >>> >>> LSARC >>> >>> 1.4.3. The Director/VP who is "Sponsoring" this project: >>> >>> robert.odea@sun.com >>> >>> 1.4.4. The name of your business unit: >>> >>> OpenSolaris Desktop >>> >>> 1.5. Email Aliases: >>> >>> 1.5.1. Responsible Manager: >>> >>> harry.lu@sun.com >>> >>> 1.5.2. Responsible Engineer: >>> >>> jerry.tan@sun.com >>> >>> 1.5.3. Marketing Manager: >>> >>> glynn.foster@sun.com >>> >>> 1.5.4. Interest List: >>> >>> desktop-discuss@opensolaris.org >>> >>> 2. Project Summary >>> >>> 2.1. Project Description: >>> >>> Raptor is a free software C library that provides a set of >>> parsers >>> and >>> serializers that generate Resource Description Framework (RDF) >>> triples >>> by parsing syntaxes or serialize the triples into a syntax. >>> >>> 4. Technical Description: >>> >>> 4.1. Details: >>> >>> The Raptor library provides a high-level interface to a set of >>> parsers >>> and serializers that generate Resource Description Framework >>> (RDF) >>> triples by parsing syntaxes or serialize the triples into >>> syntaxes. >>> >>> The supported parsing syntaxes include RDF/XML, N-Triples, >>> Turtle, >>> TRiG, >>> RSS tag soup (including all RSS and Atoms), GRDDL, RDFa and the >>> serializing syntaxes include RDF/XML (3 varieties), N-Triples, >>> Turtle, >>> RSS 1.0, Atom 1.0, GraphViz DOT and RDF/JSON. The RDF/XML >>> parser can >>> use libxml XML parsers for providing the SAX event stream. The >>> library >>> functions are arranged in an object-oriented style with >>> constructors, >>> destructors and method calls. The statements and error >>> messages are >>> delivered via callback functions. >>> >>> Raptor contains a URI-reference parsing and resolving (not >>> retrieval) >>> class (raptor_uri) sufficient for dealing with URI-references >>> inside >>> RDF. This functionality is modular and can be transparently >>> replaced >>> with another existing and compatible URI implementation. >>> >>> It also provides a URI-retrieval class (raptor_www) for wrapping >>> existing library such as libxml2 or BSD libfetch that >>> provides full >>> or partial retrieval of data from URIs and an I/O stream >>> abstraction >>> (raptor_iostream) for supportin serializing to a variety of >>> outputs. >>> >>> Raptor uses Unicode strings for RDF literals and URIs and >>> preserves >>> them throughout the library. It uses the UTF-8 encoding of >>> Unicode >>> at the API for passing in or returning Unicode strings. It is >>> intended >>> that the preservation of Unicode for URIs will support >>> Internationalized >>> Resource Identifiers (IRIs) which are still under development >>> and standardisation. >>> >>> A typical C programe that use raptor may look like this >>> >>> #include >>> >>> raptor_init(); >>> raptor_parser *p=raptor_new_parser("rdfxml"); >>> raptor_set_statement_handler(p,NULL,print_triples); >>> raptor_uri *file_uri=raptor_new_uri("http://example.org/"); >>> raptor_parse_file(p,file_uri,base_uri); >>> raptor_parse_uri(p,uri,NULL); >>> raptor_free_parser(p); >>> raptor_free_uri(file_uri); >>> raptor_finish(); >>> >>> >>> 4.2. Bug/RFE Number(s): >>> >>> 6859024 >>> >>> 4.3. In Scope: >>> >>> See above. >>> >>> 4.4. Out of Scope: >>> >>> See above. >>> >>> 4.5. Interfaces: >>> >>> Exported Interface >>> >>> Interface Classification Comments >>> ----------------------------- -------------- >>> ---------------------- >>> SUNWraptor Uncommitted Package name >>> SUNWraptor-devel Uncommitted Package name >>> /usr/bin/rapper Volatile parser utility >>> /usr/bin/raptor-config Volatile config utility >>> /usr/lib/libraptor.so.1 Volatile library >>> /usr/share/man/man1/rapper.1 Volatile man page >>> /usr/share/man/man1/raptor-config.1 >>> Volatile man page >>> /usr/share/man/man3/libraptor.3 Volatile man page >>> /usr/lib/pkgconfig/raptor.pc Volatile pc file >>> /usr/include/raptor.h Volatile Header file >>> /usr/share/gtk-doc/html/raptor Volatile help file >>> >>> Imported Interface >>> >>> Interface Classification ARC case Comment >>> -------- --------------- ---------- ------------------------------- >>> XSLT Uncommitted PSARC/2002/244 >>> XML2 Committed PSARC/2008/032 >>> >>> >>> 4.6. Doc Impact: >>> >>> Help docs and man page >>> >>> 4.7. Admin/Config Impact: >>> >>> None. >>> >>> 4.8. HA Impact: >>> >>> None. >>> >>> 4.9. I18N/L10N Impact: >>> >>> The OpenSolaris Desktop team and the G11N are working >>> together to >>> evaluate and provide I18N/L10N support. >>> >>> 4.10. Packaging & Delivery: >>> >>> Adds two new packages: >>> Package Cluster Comment >>> ------------------ ------------ ---------- >>> SUNWraptor SUNW(gnapps) base package for >>> libraries >>> SUNWraptor-devel SUNW(gnapps) dev pkg for raptor >>> >>> 4.11. Security Impact: >>> >>> None >>> >>> 4.12. Dependencies: >>> >>> Refer to Imported Interface table. >>> >>> >>> 5. Reference Documents: >>> >>> [1] RDF >>> http://www.w3.org/TR/rdf-concepts/ >>> http://www.w3.org/TR/rdf-syntax-grammar/ >>> http://www.w3.org/2001/sw/RDFCore/ >>> http://www.w3.org/TR/rdf-testcases/#ntriples >>> http://www.dajobe.org/2004/01/turtle/ >>> >>> [2] raptor homepage: >>> http://librdf.org/raptor/ >>> >>> [3] Related ARC Cases: >>> >>> PSARC/2002/244 Using XSLT and libxslt in Solaris >>> PSARC/2008/032 libxml2 upgrade to 2.6.31 >>> PSARC/2001/175 Using XML and libxml in Solaris >>> >>> >>> _______________________________________________ >>> desktop-discuss mailing list >>> desktop-discuss@opensolaris.org >>> >>> >> >> >> >> > -- Jan Hnatek jan.hnatek@sun.com From Jerry.Tan@sun.com Fri Jul 31 01:50:17 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6V8oHwc023876 for ; Fri, 31 Jul 2009 01:50:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6V8oGXq014549 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 31 Jul 2009 01:50:17 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN0020L1VS6O00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 01:50:16 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN000N51VRQF30@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 01:50:16 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6V8oFXP004941 for ; Fri, 31 Jul 2009 08:50:15 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNN001001I14Y00@mail-apac.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 16:50:15 +0800 (SGT) Received: from [129.158.217.235] ([unknown] [129.158.217.235]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNN002UD1VPFJD0@mail-apac.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 16:50:14 +0800 (SGT) Date: Fri, 31 Jul 2009 16:50:30 +0800 From: Jerry Tan Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A72A1DF.10302@sun.com> Sender: Jerry.Tan@sun.com To: Jan Hnatek Cc: Lukas Oboril , Brian Cameron , LSARC-ext@sun.com, Desktop Discuss Message-id: <4A72B056.8040301@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A725760.5010102@sun.com> <4A72A1DF.10302@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 8380 HI, Jan. I will add 64bit version for it. Jan Hnatek : > Hi Jerry, > > please include the 64bit libraries too. > > For example the redland and soprano libraries > in the KDE project depend on raptor and it would > be impossible/problematic to switch to using > system-delivered raptor libraries. > > Regards, > hnhn > > Jerry Tan wrote: >> >> Hi, Lukas, >> >> because the only application that use raptor is tracker new version, >> it is a 32bit application. >> so we don't build 64bit binary for raptor. >> >> If we got a request that some 64bit application use it, >> we will release 64bit library for it. >> >> thanks. >> >> >>> Brian, >>> >>> I do not see 64bit version of library. >>> >>> >>> Luc >>> >>> On Thu, Jul 30, 2009 at 1:31 AM, Brian >>> Cameron wrote: >>> >>>> I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will >>>> timeout on August 12th. See attached onepager. >>>> >>>> Brian >>>> >>>> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >>>> Copyright 2007 Sun Microsystems >>>> >>>> 1. Introduction >>>> 1.1. Project/Component Working Name: >>>> >>>> Raptor 1.4.19 >>>> >>>> 1.2. Name of Document Author/Supplier: >>>> >>>> Author: Jerry Tan >>>> Sponsor: Brian Cameron >>>> >>>> 1.3. Date of This Document: >>>> >>>> 07/21/09 >>>> >>>> 1.4. Name of Major Document Customer(s)/Consumer(s): >>>> >>>> 1.4.1. The PAC or CPT you expect to review your project: >>>> >>>> Solaris PAC >>>> >>>> 1.4.2. The ARC(s) you expect to review your project: >>>> >>>> LSARC >>>> >>>> 1.4.3. The Director/VP who is "Sponsoring" this project: >>>> >>>> robert.odea@sun.com >>>> >>>> 1.4.4. The name of your business unit: >>>> >>>> OpenSolaris Desktop >>>> >>>> 1.5. Email Aliases: >>>> >>>> 1.5.1. Responsible Manager: >>>> >>>> harry.lu@sun.com >>>> >>>> 1.5.2. Responsible Engineer: >>>> >>>> jerry.tan@sun.com >>>> >>>> 1.5.3. Marketing Manager: >>>> >>>> glynn.foster@sun.com >>>> >>>> 1.5.4. Interest List: >>>> >>>> desktop-discuss@opensolaris.org >>>> >>>> 2. Project Summary >>>> >>>> 2.1. Project Description: >>>> >>>> Raptor is a free software C library that provides a set of >>>> parsers >>>> and >>>> serializers that generate Resource Description Framework (RDF) >>>> triples >>>> by parsing syntaxes or serialize the triples into a syntax. >>>> >>>> 4. Technical Description: >>>> >>>> 4.1. Details: >>>> >>>> The Raptor library provides a high-level interface to a set of >>>> parsers >>>> and serializers that generate Resource Description Framework >>>> (RDF) >>>> triples by parsing syntaxes or serialize the triples into >>>> syntaxes. >>>> >>>> The supported parsing syntaxes include RDF/XML, N-Triples, >>>> Turtle, >>>> TRiG, >>>> RSS tag soup (including all RSS and Atoms), GRDDL, RDFa and >>>> the >>>> serializing syntaxes include RDF/XML (3 varieties), N-Triples, >>>> Turtle, >>>> RSS 1.0, Atom 1.0, GraphViz DOT and RDF/JSON. The RDF/XML >>>> parser can >>>> use libxml XML parsers for providing the SAX event stream. The >>>> library >>>> functions are arranged in an object-oriented style with >>>> constructors, >>>> destructors and method calls. The statements and error >>>> messages are >>>> delivered via callback functions. >>>> >>>> Raptor contains a URI-reference parsing and resolving (not >>>> retrieval) >>>> class (raptor_uri) sufficient for dealing with >>>> URI-references inside >>>> RDF. This functionality is modular and can be transparently >>>> replaced >>>> with another existing and compatible URI implementation. >>>> >>>> It also provides a URI-retrieval class (raptor_www) for >>>> wrapping >>>> existing library such as libxml2 or BSD libfetch that >>>> provides full >>>> or partial retrieval of data from URIs and an I/O stream >>>> abstraction >>>> (raptor_iostream) for supportin serializing to a variety of >>>> outputs. >>>> >>>> Raptor uses Unicode strings for RDF literals and URIs and >>>> preserves >>>> them throughout the library. It uses the UTF-8 encoding of >>>> Unicode >>>> at the API for passing in or returning Unicode strings. It is >>>> intended >>>> that the preservation of Unicode for URIs will support >>>> Internationalized >>>> Resource Identifiers (IRIs) which are still under development >>>> and standardisation. >>>> >>>> A typical C programe that use raptor may look like this >>>> >>>> #include >>>> >>>> raptor_init(); >>>> raptor_parser *p=raptor_new_parser("rdfxml"); >>>> raptor_set_statement_handler(p,NULL,print_triples); >>>> raptor_uri *file_uri=raptor_new_uri("http://example.org/"); >>>> raptor_parse_file(p,file_uri,base_uri); >>>> raptor_parse_uri(p,uri,NULL); >>>> raptor_free_parser(p); >>>> raptor_free_uri(file_uri); >>>> raptor_finish(); >>>> >>>> >>>> 4.2. Bug/RFE Number(s): >>>> >>>> 6859024 >>>> >>>> 4.3. In Scope: >>>> >>>> See above. >>>> >>>> 4.4. Out of Scope: >>>> >>>> See above. >>>> >>>> 4.5. Interfaces: >>>> >>>> Exported Interface >>>> >>>> Interface Classification Comments >>>> ----------------------------- -------------- >>>> ---------------------- >>>> SUNWraptor Uncommitted Package name >>>> SUNWraptor-devel Uncommitted Package name >>>> /usr/bin/rapper Volatile parser utility >>>> /usr/bin/raptor-config Volatile config utility >>>> /usr/lib/libraptor.so.1 Volatile library >>>> /usr/share/man/man1/rapper.1 Volatile man page >>>> /usr/share/man/man1/raptor-config.1 >>>> Volatile man page >>>> /usr/share/man/man3/libraptor.3 Volatile man page >>>> /usr/lib/pkgconfig/raptor.pc Volatile pc file >>>> /usr/include/raptor.h Volatile Header file >>>> /usr/share/gtk-doc/html/raptor Volatile help file >>>> >>>> Imported Interface >>>> >>>> Interface Classification ARC case Comment >>>> -------- --------------- ---------- >>>> ------------------------------- >>>> XSLT Uncommitted PSARC/2002/244 >>>> XML2 Committed PSARC/2008/032 >>>> >>>> >>>> 4.6. Doc Impact: >>>> >>>> Help docs and man page >>>> >>>> 4.7. Admin/Config Impact: >>>> >>>> None. >>>> >>>> 4.8. HA Impact: >>>> >>>> None. >>>> >>>> 4.9. I18N/L10N Impact: >>>> >>>> The OpenSolaris Desktop team and the G11N are working >>>> together to >>>> evaluate and provide I18N/L10N support. >>>> >>>> 4.10. Packaging & Delivery: >>>> >>>> Adds two new packages: >>>> Package Cluster Comment >>>> ------------------ ------------ ---------- >>>> SUNWraptor SUNW(gnapps) base package for >>>> libraries >>>> SUNWraptor-devel SUNW(gnapps) dev pkg for raptor >>>> >>>> 4.11. Security Impact: >>>> >>>> None >>>> >>>> 4.12. Dependencies: >>>> >>>> Refer to Imported Interface table. >>>> >>>> >>>> 5. Reference Documents: >>>> >>>> [1] RDF >>>> http://www.w3.org/TR/rdf-concepts/ >>>> http://www.w3.org/TR/rdf-syntax-grammar/ >>>> http://www.w3.org/2001/sw/RDFCore/ >>>> http://www.w3.org/TR/rdf-testcases/#ntriples >>>> http://www.dajobe.org/2004/01/turtle/ >>>> >>>> [2] raptor homepage: >>>> http://librdf.org/raptor/ >>>> >>>> [3] Related ARC Cases: >>>> >>>> PSARC/2002/244 Using XSLT and libxslt in Solaris >>>> PSARC/2008/032 libxml2 upgrade to 2.6.31 >>>> PSARC/2001/175 Using XML and libxml in Solaris >>>> >>>> >>>> _______________________________________________ >>>> desktop-discuss mailing list >>>> desktop-discuss@opensolaris.org >>>> >>>> >>> >>> >>> >>> >> > From storycrafter@gmail.com Fri Jul 31 07:43:44 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VEhidI003185 for ; Fri, 31 Jul 2009 07:43:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6VEheHb056082; Fri, 31 Jul 2009 08:43:42 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN00G0BI8TA100@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Jul 2009 07:43:41 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN001N3I8SQD60@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Jul 2009 07:43:40 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6VEgSv0022924; Fri, 31 Jul 2009 14:43:40 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay42i.sun.com with ESMTP id BT-MMP-1485919; Fri, 31 Jul 2009 14:43:40 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-28922874; Fri, 31 Jul 2009 14:43:31 +0000 (Z) Received: from mail-pz0-f204.google.com ([209.85.222.204] [209.85.222.204]) by relay4i.sun.com with ESMTP id BT-MMP-8403694; Fri, 31 Jul 2009 14:43:31 +0000 (Z) Received: by pzk42 with SMTP id 42so1570206pzk.17 for ; Fri, 31 Jul 2009 07:42:57 -0700 (PDT) Received: by 10.140.200.14 with SMTP id x14mr2028266rvf.283.1249051377305; Fri, 31 Jul 2009 07:42:57 -0700 (PDT) Received: from ?172.16.202.89? (68-252-106-20.ded.ameritech.net [68.252.106.20]) by mx.google.com with ESMTPS id k41sm19013118rvb.17.2009.07.31.07.42.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 07:42:56 -0700 (PDT) Date: Fri, 31 Jul 2009 09:42:54 -0500 From: Mark Martin Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A726103.6010001@sun.com> To: Jerry Tan Cc: Brian Cameron , LSARC-ext@sun.com, Desktop Discuss Message-id: <4A7302EE.8090700@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=02SV9EUvfK3WXqTYMhah8jojcI7mmscEJizbyrX++s4=; b=t4a0cncUNNvE5qUUpdZwdMoJ3Z6/1lgSKg0JI+OaUU+2ZG0jN6u0Yp8Ji6yAMxcdze jAqpJQpfJrdQNbtpC4O1Ym0bkxHdUM/6ijGQm74GcEMRQdf7HXxWWWMWDKL/hS38fG6Q upDjWbBb/1qU/QORMVcnuIUZMdQ2XMa9ATAJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ttiSbzMwDEL8MHK1iZ0FUmPr4QCee0dEptTZfH+F0kukmyIE2otFeomATzej64nYu7 1FINrefBMFgUMTbCbMILVNs1ZEopCtuy9DD8NHemdC3g2w1qtzAFrVCATXV7tgfPscoi UA+bhYvLF1fA5XPAkXWyPYnqsDHsc8nJ1zYJM= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 7.926sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Status: RO Content-Length: 5107 Jerry Tan wrote: > Hi, Mark. > > please see my comments inline. > thanks. > > Mark Martin : >> Brian Cameron wrote: >>> >>> I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will >>> timeout on August 12th. See attached onepager. >>> >>> Brian >> <...excerpted from the attachment...> >>> 4.5. Interfaces: >>> Exported Interface >>> Interface Classification Comments >>> ----------------------------- -------------- >>> ---------------------- >>> SUNWraptor Uncommitted Package name >>> SUNWraptor-devel Uncommitted Package name >>> /usr/bin/rapper Volatile parser utility >>> /usr/bin/raptor-config Volatile config utility >>> /usr/lib/libraptor.so.1 Volatile library >>> /usr/share/man/man1/rapper.1 Volatile man page >>> /usr/share/man/man1/raptor-config.1 >>> Volatile man page >>> /usr/share/man/man3/libraptor.3 Volatile man page >>> /usr/lib/pkgconfig/raptor.pc Volatile pc file >>> /usr/include/raptor.h Volatile Header file >>> /usr/share/gtk-doc/html/raptor Volatile help file >> I notice that most of the exported interfaces are "Volatile". This >> seems low, especially since the upstream itself seems committed to >> stability (e.g. the notice regarding the ABI/API change on the front >> page). Isn't "Uncommitted" more appropriate? > From its release note and changelog, > http://librdf.org/raptor/RELEASE.html#rel1_4_19 > "New development will move to raptor 2 where a planned ABI and API > break will happen" > So I would rather call it as "Volatile". > But that's for a new major release of raptor. It mentions the next revision is targeting a stable interface. That's fine -- you've considered it, so I'll move along. >> >> Also, is this *library* racing another FOSS product -- i.e. will we >> see another consuming application show up soon? I ask merely out of >> curiosity -- I believe we have a pattern of delivering (FOSS >> enabling) libraries in LSARC, whereas PSARC often challenges >> libraries without consumers. And this seems like such a specialized >> library. . . > Tracker, one desktop search tool, see LSARC/2008/375/ > its new version (maybe 0.7.0) is depending on libraptor. > the release date is not fixed, but hopefully it will be released by > the end of this year. > so I made this ARC case to integrate its new dependency. Got it now, thanks. >> >> Also, another point of personal clarification -- I notice not all >> projects complete a FOSS checklist. This one didn't seem to. I >> suspect that's fine, except that in this particular case, I couldn't >> find a binding level. I notice that's an explicit question in the >> FOSS checklist, but reviewing many recent one-pagers reveals that >> this detail is very often omitted. What is the binding level here? >> > From FOSS checklist Document > > " After the check list is completed the project team should be able > to determine if a project can be automatically approved. This will > occur > if all checks result in no "ARC review required" answers. " > > > This ARC case is made by my team to request ARC review, so we did not > complete a FOSS checklist. > we plan to integrate raptor 1.4.19 into NV. > OK, I see. Although I understood the intent and nature of the FOSS checklist, I was never fully clued in on when it was an absolute necessity or what the guidance was on filling it out. It sounds like it's a tool when you're not quite sure whether to fast-track or not, but if you're certain from the get-go, then it's not required. I'm suppose I'm OK with that. > >> One final nit -- are we really interested in delivering raptor.pc? >> It's not really been common practice up until now to deliver those >> ./configure artifacts. > raptor.pc is needed. > In fact,a library bundled one pc file is recommended, since > pkg-config can use it to get CFLAGS, LIB flags. > and pkg-config is used very often. > > IMO, raptor-confg , which can be used to get CFLAGS and LIBS , will be > removed in its future version. > since release a pc file is more common. > > Well for good or bad, I've noticed .pc files before, questioned them, and the teams have simply removed them. Knowing now that they're part and parcel for projects is fine, so I don't have a problem if providing them is a norm. Something to note here is that it seems like a somewhat emergent interface artifact standard, and that it's probably safe to *expect* this build configuration interface to be present for most FOSS type projects, much like header files or libraries. Is there any internal guidance or documentation on this, or is this just an unspoken common practice among teams nowadays? We might want to make sure that this expectation is communicated to external contributors and systems as well (e.g. SourceJuicer). From Alan.Coopersmith@sun.com Fri Jul 31 08:43:19 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VFhIRs008166 for ; Fri, 31 Jul 2009 08:43:18 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6VFhI4U023687 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 31 Jul 2009 09:43:18 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN00405L05C200@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 08:43:17 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN001WDL05Q5C0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 08:43:17 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6VFhH5f019654 for ; Fri, 31 Jul 2009 08:43:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNN00L00KE3O100@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 08:43:16 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNN00E46L04NIE0@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 08:43:16 -0700 (PDT) Date: Fri, 31 Jul 2009 08:43:16 -0700 From: Alan Coopersmith Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A7302EE.8090700@gmail.com> Sender: Alan.Coopersmith@sun.com To: Mark Martin Cc: Jerry Tan , Brian Cameron , LSARC-ext@sun.com, Desktop Discuss Message-id: <4A731114.2040505@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 492 Mark Martin wrote: > Well for good or bad, I've noticed .pc files before, questioned them, > and the teams have simply removed them. You sure you're not confusing those with .la files? libtool-generated .la files should not be delivered, but .pc files are used by pkg-config so that packages with dependencies can determine what flags to use for building and linking. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From storycrafter@gmail.com Fri Jul 31 09:45:30 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VGjTY5009660 for ; Fri, 31 Jul 2009 09:45:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6VGjM0G017942; Fri, 31 Jul 2009 17:45:24 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN00G0JNVNK200@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Jul 2009 09:45:23 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN00AJINVNMS30@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Jul 2009 09:45:23 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6VGUtbZ026386; Fri, 31 Jul 2009 16:45:22 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-1496626; Fri, 31 Jul 2009 16:45:22 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-31472819; Fri, 31 Jul 2009 16:45:19 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.182] [209.85.146.182]) by relay4i.sun.com with ESMTP id BT-MMP-8613134; Fri, 31 Jul 2009 16:45:19 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id m38so318872waf.8 for ; Fri, 31 Jul 2009 09:44:48 -0700 (PDT) Received: by 10.114.61.9 with SMTP id j9mr2672821waa.32.1249058688865; Fri, 31 Jul 2009 09:44:48 -0700 (PDT) Received: from ?172.16.202.89? (68-252-106-20.ded.ameritech.net [68.252.106.20]) by mx.google.com with ESMTPS id k37sm5486304waf.7.2009.07.31.09.44.45 (version=TLSv1/SSLv3 cipher=RC4-MD5) ; Fri, 31 Jul 2009 09:44:46 -0700 (PDT) Date: Fri, 31 Jul 2009 11:44:44 -0500 From: Mark Martin Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A731114.2040505@sun.com> To: Alan Coopersmith Cc: Jerry Tan , Brian Cameron , LSARC-ext@sun.com, Desktop Discuss Message-id: <4A731F7C.5020009@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QSeZ4CyV74DcmT32va9KdmecXfb6cnzrD3WASSXubcI=; b=b2U2YtgeoOpmbSHWlQXCTVvxYNpX+5xtJVluVON+l2/+Co/exIvcFRVm+WW7T7UqW/ wSsaLypwaV0lbNrtM9X+aT2aqkT5Rg4+fpmNxREp/7jNRRAQ87xCu3UKx9WlPwEG6DlG lhmPhuMjby/PR+gFUZwKD5UIbzHLKfE7yJP34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=AiqT3ELqMAxOEDhJM6GgeG59a0YwQ696uLKIvh0ePWpEBtDjWnU4I8dE1AkZ0nsFcC HL4k0warthN8laHE2Fg3ABnzsdgUe+PVa9aO9BFFGSbBaPhmEULclpkwC+bqb6prUgBR YD9ILRpJUDnavZMk7qyDushSLrh0+mtnJNg9A= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 3.104sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Status: RO Content-Length: 1814 Alan Coopersmith wrote: > Mark Martin wrote: > >> Well for good or bad, I've noticed .pc files before, questioned them, >> and the teams have simply removed them. >> > > You sure you're not confusing those with .la files? libtool-generated > .la files should not be delivered, but .pc files are used by pkg-config > so that packages with dependencies can determine what flags to use for > building and linking. > > Nah, I meant ".pc" files. I should correct myself, though. They weren't removed -- instead the stability on those particular artifacts went from Uncommitted -> Cons. Private. http://arc.opensolaris.org/caselog/LSARC/2008/782/mail I don't remember if this happened on other cases -- this was the most recent from memory. I do understand what they're used for, these just aren't something I'm used to seeing when I do my own app building. Grant it, I've only dabbled in producing anything resembling redistributable packages, and I certainly don't know what the standard procedure is for Sun teams. I'm trying to determine if there is any need for definition on these files, i.e. should they be versioned? If these files are to become first class citizens, just like a .h file or a .so, should we at least have something describing them, and how to use them? Just like with jar files, it seems a bit short sited to just let these artifacts be delivered without any attempt to define both production and consumption in view of stability. In this particular case we've pretty much marked the whole shooting match as volatile, so it's probably moot, I admit. I don't want to get into a "not this case" position, so I'll only suggest to the team to slap a version number in the .pc file name (now and in the future) and conclude my comments on this case. From Brian.Cameron@sun.com Fri Jul 31 10:26:09 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VHQ9GG010736 for ; Fri, 31 Jul 2009 10:26:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6VHQ5jn014386 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 31 Jul 2009 10:26:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN00E1VPRJ4Q00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:26:07 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN006H1PRIL6A0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:26:06 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6VHQ6C1018217 for ; Fri, 31 Jul 2009 17:26:06 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNN00000PI5SM00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 11:26:06 -0600 (MDT) Received: from [129.153.250.84] ([unknown] [129.153.250.84]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNN000C7PRF9J20@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 11:26:04 -0600 (MDT) Date: Fri, 31 Jul 2009 12:26:15 -0500 From: Brian Cameron Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A7302EE.8090700@gmail.com> Sender: Brian.Cameron@sun.com To: Mark Martin Cc: Jerry Tan , LSARC-ext@sun.com, Desktop Discuss Message-id: <4A732937.9060307@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090622) Status: RO Content-Length: 3427 Mark: >>> One final nit -- are we really interested in delivering raptor.pc? >>> It's not really been common practice up until now to deliver those >>> ./configure artifacts. >> raptor.pc is needed. >> In fact,a library bundled one pc file is recommended, since >> pkg-config can use it to get CFLAGS, LIB flags. >> and pkg-config is used very often. >> >> IMO, raptor-confg , which can be used to get CFLAGS and LIBS , will be >> removed in its future version. >> since release a pc file is more common. > > Well for good or bad, I've noticed .pc files before, questioned them, > and the teams have simply removed them. In general, this would be bad. The only time you would not want to deliver a .pc file would be in the situation where the interfaces were truly private and you didn't want users to ever build against them. For example, if you delivered a library without the header files specifically so that users would not link against the library, then it wouldn't make sense to deliver any associated .pc files. I can't think of a situation where you would not want to deliver the .pc file if you did deliver the header files and other resources needed for building with the module's interfaces. > Knowing now that they're part > and parcel for projects is fine, so I don't have a problem if providing > them is a norm. Something to note here is that it seems like a somewhat > emergent interface artifact standard, and that it's probably safe to > *expect* this build configuration interface to be present for most FOSS > type projects, much like header files or libraries. If you read the pkg-config manpage, you will see that the pkg-config interfaces (such as the normal default location for .pc files) are Committed. Most free/open source modules which use autotools also use pkg-config to determine if needed dependencies are present, and to figure out what arguments are needed to compile and link against a given library. The pkg-config interfaces (e.g. the keys in the .pc file are very stable, and have not broken in a backwards incompatible way since pkg-config was first introduced in Solaris 10. In practice, the .pc file namespace also tends to be very stable. Modules don't tend to change the .pc filenames they use, for example. Since we integrated pkg-config in Solaris 10, I have never heard of any interface stability problem that has arisen from the various .pc files installed on Solaris. > Is there any > internal guidance or documentation on this, or is this just an unspoken > common practice among teams nowadays? We might want to make sure that > this expectation is communicated to external contributors and systems as > well (e.g. SourceJuicer). The Desktop team normally ships all .pc files provided with free software modules, unless we don't ship the headers or other needed files required to build against the module. Unless there is a need to deny people the ability to easily build against a given module, it doesn't make sense to not ship the .pc file. To my knowledge, pkg-config is only used by various FOSS project, and I don't believe it is used by many projects written internally at Sun. However, if Sun were to write a module that made use of pkg-config, then there should be some common sense rules about naming the .pc file sensibly, especially if there is a desire for multiple versions of the module to be parallel installable. Brian From danek.duvall@Sun.COM Fri Jul 31 10:39:36 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VHdaBd010851 for ; Fri, 31 Jul 2009 10:39:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6VHdDLc029811 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 31 Jul 2009 10:39:36 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN00E05QDYZ000@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:39:34 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN006OXQDXL4C0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:39:34 -0700 (PDT) Received: from smelly.SFBay.Sun.COM (smelly.SFBay.Sun.COM [129.146.228.142]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6VHdW4A049712; Fri, 31 Jul 2009 10:39:32 -0700 (PDT) Received: from smelly.SFBay.Sun.COM (smelly [127.0.0.1]) by smelly.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n6VHdWAa007344; Fri, 31 Jul 2009 10:39:32 -0700 (PDT) Received: (from dduvall@localhost) by smelly.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6VHdWvk007343; Fri, 31 Jul 2009 10:39:32 -0700 (PDT) Date: Fri, 31 Jul 2009 10:39:32 -0700 From: Danek Duvall Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A731F7C.5020009@gmail.com> To: Mark Martin Cc: Alan Coopersmith , Jerry Tan , Brian Cameron , LSARC-ext@Sun.COM, Desktop Discuss Message-id: <20090731173932.GN29874@smelly.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-23) Status: RO Content-Length: 520 On Fri, Jul 31, 2009 at 11:44:44AM -0500, Mark Martin wrote: > I'll only suggest to the team to slap a version number in the .pc file > name (now and in the future) and conclude my comments on this case. Yipes, no, please don't. The names of the files without the .pc extensions are input arguments to pkg-config, and so are hard-coded in configure scripts around the world. These names are generally pretty stable as interfaces go, and modification would make Solaris gratuitously (and uselessly) different. Danek From Brian.Cameron@sun.com Fri Jul 31 10:45:28 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VHjReC010931 for ; Fri, 31 Jul 2009 10:45:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6VHjNoi021436 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 31 Jul 2009 11:45:27 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN00F0JQNQEM00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:45:26 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN0068LQNPL1B0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:45:25 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6VHjPBb000187 for ; Fri, 31 Jul 2009 17:45:25 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNN00800PLK7F00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 11:45:25 -0600 (MDT) Received: from [129.153.250.84] ([unknown] [129.153.250.84]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNN003VGQN6C140@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 11:45:07 -0600 (MDT) Date: Fri, 31 Jul 2009 12:45:19 -0500 From: Brian Cameron Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A731F7C.5020009@gmail.com> Sender: Brian.Cameron@sun.com To: Mark Martin Cc: Alan Coopersmith , Jerry Tan , LSARC-ext@sun.com, Desktop Discuss Message-id: <4A732DAF.8070904@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090622) Status: RO Content-Length: 5409 Mark: >> You sure you're not confusing those with .la files? libtool-generated >> .la files should not be delivered, but .pc files are used by pkg-config >> so that packages with dependencies can determine what flags to use for >> building and linking. >> > Nah, I meant ".pc" files. I should correct myself, though. They > weren't removed -- instead the stability on those particular artifacts > went from Uncommitted -> Cons. Private. > http://arc.opensolaris.org/caselog/LSARC/2008/782/mail > I don't remember if this happened on other cases -- this was the most > recent from memory. This doesn't really make sense. Installing a private file to /usr/lib/pkgconfig, which is a Committed interface, is counter intuitive. All files in this directory are visible, by default, to pkg-config, so marking it private doesn't really hide it from use in any practical way. If you really want to make a .pc file "private", the way to do this would be to install it to a different private directory, and force users to set the PKG_CONFIG_PATH environment variable to access it. Refer to the pkg-config manpage to see how PKG_CONFIG_PATH works. > I do understand what they're used for, these just aren't something I'm > used to seeing when I do my own app building. They tend to be only used if building with autotools. For example, autoconf contains macros which makes calling pkg-config very easy. You could use pkg-config without using autotools, but I don't think that is very common. If you don't work with modules that build with autotools, then this would explain why you aren't used to seeing them. > I'm > trying to determine if there is any need for definition on these files, > i.e. should they be versioned? It depends. For example, if you look in /usr/lib/pkgconfig, you will notice the gtk+-2.0.pc file. Since GTK+ is intended to be parallel installable with GTK 1.0, they use separate .pc files. Typically, you want the /usr/lib/pkgconfig directory to contain the versions of the libraries you want users to link against by default. If for some reason, you wanted to ship two versions of a library that had the same .pc file name, you can also manage this. For example, lets say you wanted to ship GTK 2.14 and 2.16 for some reason. In this case, both have the same .pc file name. Perhaps you might want to do this because some specific program needs the older GTK+ version for some odd reason. In this case you would probably put the 2.16 version of the .pc file in /usr/lib/pkgconfig so that users would get the latest version by default. Then you would provide an alternative pc file for 2.14 in a different directory, perhaps /usr/lib/gtk-2.14/pkgconfig (or something) for people to use if they wanted to use the older version. Users would set PKG_CONFIG_PATH to /usr/lib/gtk-2.14/pkgconfig so the older GTK+ .pc file would be used. For a real-life example of this, you can see that the Python 2.6 pkgconfig files are in the default pkgconfig directory: /usr/lib/pkgconfig, but the Python 2.4 pkgconfig interfaces are in /usr/lib/python2.4/pkgconfig. This way, users link against Python 2.6 by default, but they can set PKG_CONFIG_PATH to the /usr/lib/python2.4/pkgconfig directory if they really want to use Python 2.4. This, hopefully, gives you some real examples of how .pc files are managed in practice. > If these files are to become first class citizens, just like a .h > file or a .so, Since the pkg-config interfaces are already Committed, I'd think they are already first-class citizens. > should we at least have > something describing them, and how to use them? Do you find the pkg-config manpage incomplete? > Just like with jar > files, it seems a bit short sited to just let these artifacts be > delivered without any attempt to define both production and consumption > in view of stability. The external FOSS community seems to be managing them pretty well. I have never heard of any problems, nor am I aware of any stability issues the Desktop team has encountered in the many years we have delivered the bulk of the .pc files you find on Solaris. Do you have an example of a specific issue that you are concerned about? > In this particular case we've pretty much marked > the whole shooting match as volatile, so it's probably moot, I admit. Really .pc files should probably be listed as Uncommitted. Listing it as Volatile doesn't really make sense, and doesn't reflect how they are used. The interfaces of a .pc file, the filename used for a given module, and the file location are not Volatile. > I > don't want to get into a "not this case" position, so I'll only suggest > to the team to slap a version number in the .pc file name (now and in > the future) and conclude my comments on this case. This would be inappropriate. Other modules refer to the .pc files by filename. So, changing the filename would break any module which depends on this interface. If this library is intended to be parallel-installable, then a version number may be appropriate to include in the filename. However, this change should be done at the source upstream, and not a change made by a specific distro. Changing the filename breaks how it works. As I say above, if you want to install multiple versions of the same .pc file, you do this by installing them to separate directories, not by changing the filename. Brian From Alan.Coopersmith@Sun.COM Fri Jul 31 10:52:38 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VHqbeA011014 for ; Fri, 31 Jul 2009 10:52:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6VHqZBX002260 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 1 Aug 2009 01:52:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN00603QZM9300@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:52:34 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN00AMRQZLMEB0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:52:33 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6VHqXDN025399 for ; Fri, 31 Jul 2009 10:52:33 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNN00H00QXC3Z00@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 10:52:33 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNN00A85QZ82E30@fe-sfbay-09.sun.com>; Fri, 31 Jul 2009 10:52:21 -0700 (PDT) Date: Fri, 31 Jul 2009 10:52:20 -0700 From: Alan Coopersmith Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <20090731173932.GN29874@smelly.SFBay.Sun.COM> Sender: Alan.Coopersmith@Sun.COM To: Danek Duvall Cc: Mark Martin , Jerry Tan , Brian Cameron , LSARC-ext@Sun.COM, Desktop Discuss Message-id: <4A732F54.4070907@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> <20090731173932.GN29874@smelly.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1060 Danek Duvall wrote: > On Fri, Jul 31, 2009 at 11:44:44AM -0500, Mark Martin wrote: > >> I'll only suggest to the team to slap a version number in the .pc file >> name (now and in the future) and conclude my comments on this case. > > Yipes, no, please don't. The names of the files without the .pc extensions > are input arguments to pkg-config, and so are hard-coded in configure > scripts around the world. These names are generally pretty stable as > interfaces go, and modification would make Solaris gratuitously (and > uselessly) different. Some upstream projects do include the major version number in the file name, so that you can distinguish between ABI incompatible versions, such as gtk+ 1.x and gtk+ 2.x, but putting minor versions would break compatibility needlessly with each minor release. One of the metadata items inside the pc file is the full version information, which can be queried via pkg-config --modversion. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From storycrafter@gmail.com Fri Jul 31 13:12:37 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VKCaxx018129 for ; Fri, 31 Jul 2009 13:12:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6VKCS5b027255; Fri, 31 Jul 2009 21:12:31 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN00201XGTBX00@nwk-avmta-2.sfbay.sun.com>; Fri, 31 Jul 2009 13:12:29 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN00IVGXGT7L70@nwk-avmta-2.sfbay.sun.com>; Fri, 31 Jul 2009 13:12:29 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6VK715d009684; Fri, 31 Jul 2009 20:12:29 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay42i.sun.com with ESMTP id BT-MMP-1511322; Fri, 31 Jul 2009 20:12:28 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-29426953; Fri, 31 Jul 2009 20:12:28 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.177] [209.85.146.177]) by relay4i.sun.com with ESMTP id BT-MMP-8970560; Fri, 31 Jul 2009 20:12:28 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id m38so331639waf.8 for ; Fri, 31 Jul 2009 13:11:37 -0700 (PDT) Received: by 10.114.37.2 with SMTP id k2mr2971641wak.68.1249071097397; Fri, 31 Jul 2009 13:11:37 -0700 (PDT) Received: from ?172.16.202.89? (68-252-106-20.ded.ameritech.net [68.252.106.20]) by mx.google.com with ESMTPS id v9sm5694592wah.1.2009.07.31.13.11.34 (version=TLSv1/SSLv3 cipher=RC4-MD5) ; Fri, 31 Jul 2009 13:11:36 -0700 (PDT) Date: Fri, 31 Jul 2009 15:11:33 -0500 From: Mark Martin Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A732DAF.8070904@sun.com> To: Brian Cameron Cc: Alan Coopersmith , Jerry Tan , LSARC-ext@sun.com, Desktop Discuss Message-id: <4A734FF5.3060005@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yioKwAOWeLCLBFcOM+XiDOIlnCkQuNFMiVrjc+uXZbQ=; b=ROaj6064oUnzwadA/eUkTRVa//9v4qrb4Jm7dgTilEowInyVqmHf7GPO9f2NDcwNBG nIUMq+xqfoxRW6biga0cv39YqYZUGkMkWj/kqcplo+uS/v78WzxLM2Efr499UJDrPuO4 LfcUbSMFXttJMOPFbO7rhXCmX/B7lwUQ1G0Zg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=JMZ7/oi+c2obPclUHkAFGv3cmRuaZO7wgSu+SPoEDoQmKQbK9F1VQmRBehuyr+G96Z HZCA5mjfCa82QroNDX6B/fKLPRVq4X/kktQFeqSB8GlqDYjam1e4y7lJbgHEij6vTmQ9 HgqPplcNq8KA6Pz1uXPPMHrceFX09sHKTqM7o= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.095sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> <4A732DAF.8070904@sun.com> User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Status: RO Content-Length: 3736 Brian Cameron wrote: > > Mark: > >> If these files are to become first class citizens, just like a .h >> file or a .so, > > Since the pkg-config interfaces are already Committed, I'd think they > are already first-class citizens. I stand corrected then. > >> should we at least have something describing them, and how to use them? > > Do you find the pkg-config manpage incomplete? Nope, just not available to me. I also missed it the first time I looked for it (I can't exactly grep on sac.eng). I've just found that there's a spreadsheet of all cases available in the root that lists at least the case name. I'm filing in the blanks now, and realizing the history gap I had was that pkg-config has been in use for a while, especially by the desktop team (and presumably others). ".pc" files are as common as dandelions, and I'm just late to the party. > >> Just like with jar files, it seems a bit short sited to just let >> these artifacts be delivered without any attempt to define both >> production and consumption in view of stability. > > The external FOSS community seems to be managing them pretty well. I > have never heard of any problems, nor am I aware of any stability issues > the Desktop team has encountered in the many years we have delivered > the bulk of the .pc files you find on Solaris. Do you have an example > of a specific issue that you are concerned about? Nope, just noted an admonishment somewhere on the pkg-config site about how the file format had changed. I didn't note when, and I certainly have no idea about how much of an impact that might have been. > >> In this particular case we've pretty much marked the whole shooting >> match as volatile, so it's probably moot, I admit. > > Really .pc files should probably be listed as Uncommitted. Listing it > as Volatile doesn't really make sense, and doesn't reflect how they are > used. The interfaces of a .pc file, the filename used for a given > module, and the file location are not Volatile. > >> I don't want to get into a "not this case" position, so I'll only >> suggest to the team to slap a version number in the .pc file name >> (now and in the future) and conclude my comments on this case. > > This would be inappropriate. Other modules refer to the .pc files by > filename. So, changing the filename would break any module which > depends on this interface. > > If this library is intended to be parallel-installable, then a version > number may be appropriate to include in the filename. However, this > change should be done at the source upstream, and not a change made by > a specific distro. Changing the filename breaks how it works. As I > say above, if you want to install multiple versions of the same .pc > file, you do this by installing them to separate directories, not by > changing the filename. Fine, I see -- especially with Danek D. and Alan C. also chiming in elsewhere on this thread. I'll withdraw the suggestion and my comments as this is clearly autotool+pkg-configuration fu I do not possess. Heck, after a recent trip down memory lane a few weeks ago with a small C project, I should probably just keep my nose out of anything that doesn't require dynamic typing or a virtual machine anyway. I'm still struggling with the knowledge that the upstream plans to migrate to a new major version any moment now, and we /seem/ to be acting here as if this is some sort of evolving, non-standard interface and we've no plans of multi-version co-existence (volatile vs. uncommitted). But the team's worked it out and I can live with that. At least as far as the .pc file versioning is concerned -- that's the upstream's problem anyway. Moving along, I've done my damage. From stefan.teleman@gmail.com Fri Jul 31 13:20:43 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VKKgA9018350 for ; Fri, 31 Jul 2009 13:20:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6VKKb5F002487; Fri, 31 Jul 2009 21:20:40 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN0040LXUEM900@brm-avmta-1.central.sun.com>; Fri, 31 Jul 2009 14:20:38 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN007GMXUDJFA0@brm-avmta-1.central.sun.com>; Fri, 31 Jul 2009 14:20:37 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6VKKbAW012384; Fri, 31 Jul 2009 20:20:37 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-484512; Fri, 31 Jul 2009 20:18:37 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-19808141; Fri, 31 Jul 2009 20:18:36 +0000 (Z) Received: from mail-vw0-f201.google.com ([209.85.212.201] [209.85.212.201]) by relay1i.sun.com with ESMTP id BT-MMP-5773895; Fri, 31 Jul 2009 20:16:01 +0000 (Z) Received: by vws39 with SMTP id 39so291585vws.17 for ; Fri, 31 Jul 2009 13:15:37 -0700 (PDT) Received: by 10.220.80.148 with SMTP id t20mr2773476vck.9.1249071337083; Fri, 31 Jul 2009 13:15:37 -0700 (PDT) Date: Fri, 31 Jul 2009 16:15:37 -0400 From: Stefan Teleman Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A731F7C.5020009@gmail.com> To: Desktop Discuss , LSARC-ext@sun.com Cc: Alan Coopersmith , Mark Martin Message-id: <1ccb59a20907311315h7d188ea0pcacf06c5ff234785@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RC8p8pUSD9D29B6Xo6Y24oC0ceE80dlCUbjE0p05P0c=; b=WU5oRkTGTHCnfkG/gYWgzJXHoDf7AVhw7c+h7BpCGeZy64ppHJFm2+EcC3x4fbSp5G zJj4cxihfNMJStQWslQ7wFo8JE0z9JaOpuCtiPzfr3RBvE18CAej1rbHFmO7HhZIveDP ei/LIBtBzI2HJiAUZWHZJi8l7pwfC91kkdHh8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=d8Kf+zr473El/vYSUnnT0h8Fzb33zYHUZpOVvBbn7kp7QS8YWaES2Qs2R1UmI0LX8s 8OQ7jtduYmfyImpVtQNvrAMoYSxnn4lM2pIWj/XGUPqN+6sLy6J/nd+tsAN1q+/v34BH TgDdmfEvjhiqfK37KRtEmKN5STqE6tPVuTSvU= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.061sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n6VKKgA9018350 Status: RO Content-Length: 1514 On Fri, Jul 31, 2009 at 12:44, Mark Martin wrote: > I do understand what they're used for, these just aren't something I'm used > to seeing when I do my own app building.  Grant it, I've only dabbled in > producing anything resembling redistributable packages, and I certainly > don't know what the standard procedure is for Sun teams.  I'm trying to > determine if there is any need for definition on these files, i.e. should > they be versioned?   If these files are to become first class citizens, just > like a .h file or a .so, should we at least have something describing them, > and how to use them?   Just like with jar files, it seems a bit short sited > to just let these artifacts be delivered without any attempt to define  both > production and consumption in view of stability.  In this particular case > we've pretty much marked the whole shooting match as volatile, so it's > probably moot, I admit.  I don't want to get into a "not this case" > position, so I'll only suggest to the team to slap a version number in the > .pc file name (now and in the future) and conclude my comments on this case. *.pc files are intended for, and used by, pkg-config. The pkg-config mechanism is widely known, has already been described. Each particular component implementation explicitly defines the version of its own pkg-config files. Why would explicit versioning be necessary for pkg-config *.pc files ? --Stefan -- Stefan Teleman KDE e.V. stefan.teleman@gmail.com From storycrafter@gmail.com Fri Jul 31 13:40:41 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VKefH5018705 for ; Fri, 31 Jul 2009 13:40:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6VKebQB036849; Fri, 31 Jul 2009 14:40:40 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNN00G15YRRD900@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Jul 2009 13:40:39 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNN00E42YRR9I10@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Jul 2009 13:40:39 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6VKSuTw005671; Fri, 31 Jul 2009 20:40:38 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-485747; Fri, 31 Jul 2009 20:40:38 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-19850516; Fri, 31 Jul 2009 20:40:38 +0000 (Z) Received: from mail-pz0-f172.google.com ([209.85.222.172] [209.85.222.172]) by relay1i.sun.com with ESMTP id BT-MMP-21601136; Fri, 31 Jul 2009 20:37:42 +0000 (Z) Received: by pzk2 with SMTP id 2so1017004pzk.30 for ; Fri, 31 Jul 2009 13:37:11 -0700 (PDT) Received: by 10.140.142.11 with SMTP id p11mr2304990rvd.191.1249072631514; Fri, 31 Jul 2009 13:37:11 -0700 (PDT) Received: from ?172.16.202.89? (68-252-106-20.ded.ameritech.net [68.252.106.20]) by mx.google.com with ESMTPS id k37sm18869415rvb.58.2009.07.31.13.37.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 13:37:10 -0700 (PDT) Date: Fri, 31 Jul 2009 15:37:08 -0500 From: Mark Martin Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <1ccb59a20907311315h7d188ea0pcacf06c5ff234785@mail.gmail.com> To: Stefan Teleman Cc: Desktop Discuss , LSARC-ext@sun.com, Alan Coopersmith Message-id: <4A7355F4.1010608@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=5XMJQAN4uhrr7yEbiHEA9HfIdHmgTXMAiast+Zv3Y0M=; b=P+lJM34CGbjRpsIUmYiMZUuDeuor+QutbckzH9t2REaXkEnamnMBIu7BtAFV5E3Qwk fah2t6PNtjbFfUTPXKIMhTF7E/eAgQTVAUvbQVlB2t191NOd9YruhRqUL34GwwJLxVXM tnwd9eYmGz25YtEXMyxmJerWzYPqT6cRUJoCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=HmoVVJcabuADVnB/GL6z4qHp1LLa2xOt9Hw7NZNbpNupcay6jwk4h0PrMX2oSC3dsL 4vWKNWXIqZUCF00zTAjdltKusYxKpuQf9y2BQLVWZ674lFJ6zpVvDjxwWwpANjvq0X3X 6w0NM7jOV8naaizILbaG96qColfNl418UL/C8= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 0.079sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> <1ccb59a20907311315h7d188ea0pcacf06c5ff234785@mail.gmail.com> User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Status: RO Content-Length: 2801 Stefan Teleman wrote: > On Fri, Jul 31, 2009 at 12:44, Mark Martin wrote: > > >> I do understand what they're used for, these just aren't something I'm used >> to seeing when I do my own app building. Grant it, I've only dabbled in >> producing anything resembling redistributable packages, and I certainly >> don't know what the standard procedure is for Sun teams. I'm trying to >> determine if there is any need for definition on these files, i.e. should >> they be versioned? If these files are to become first class citizens, just >> like a .h file or a .so, should we at least have something describing them, >> and how to use them? Just like with jar files, it seems a bit short sited >> to just let these artifacts be delivered without any attempt to define both >> production and consumption in view of stability. In this particular case >> we've pretty much marked the whole shooting match as volatile, so it's >> probably moot, I admit. I don't want to get into a "not this case" >> position, so I'll only suggest to the team to slap a version number in the >> .pc file name (now and in the future) and conclude my comments on this case. >> > > *.pc files are intended for, and used by, pkg-config. The pkg-config > mechanism is widely known, has already been described. > > Each particular component implementation explicitly defines the > version of its own pkg-config files. > > Why would explicit versioning be necessary for pkg-config *.pc files ? > Well, just for kicks... I know that Raptor is about ready to move to a version 2. I know this because there's a big warning on their front page indicating this. They also indicate that the next release of 1.4.x will only contain bug fixes (I read this as "Uncommitted", but hey, I'm new to this). How do I handle the co-existence of version 1.4.x and version 2? Do I get or need to care whether it's a Sun team that delivers that artifact into a committed interface (/usr/lib/pkgconfig)? The truth is I saw it mentioned on a couple of sites talking about pkg-config usage and it seemed like a good idea. Not breaking that which is not broken upstream seems better to me, so I'm fine with that, too[1]. Brian C. mentions you can always just copy the file with the right contents into the dir at the right time and all will work, so it's not like there's not a well known solution. As I noted in another email, I've withdrawn the suggestion -- I was ignorant of the 7 year old pkg-config case (and probably of just pkg-config in general). It's a case of upstream source preservation with which I'm totally good. It's a problem that the upstream shares. I've made peace with .pc files in cases. [1] I will still lament the fact that jar's share a similar fate. From swalker@opensolaris.org Fri Jul 31 14:14:22 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6VLELHx020640 for ; Fri, 31 Jul 2009 14:14:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6VLEDFH014006; Sat, 1 Aug 2009 05:14:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNO00N070BR0E00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Jul 2009 14:14:15 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNO00EUF0BR9O40@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Jul 2009 14:14:15 -0700 (PDT) Received: from [10.7.250.188] (punchin-client-10-7-250-188.SFBay.Sun.COM [10.7.250.188]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6VLEEIW633809; Fri, 31 Jul 2009 14:14:15 -0700 (PDT) Date: Fri, 31 Jul 2009 16:14:14 -0500 From: Shawn Walker Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <1ccb59a20907311315h7d188ea0pcacf06c5ff234785@mail.gmail.com> To: Stefan Teleman Cc: Desktop Discuss , LSARC-ext@sun.com, Alan Coopersmith Message-id: <4A735EA6.1060902@opensolaris.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> <1ccb59a20907311315h7d188ea0pcacf06c5ff234785@mail.gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 1642 Stefan Teleman wrote: > On Fri, Jul 31, 2009 at 12:44, Mark Martin wrote: > >> I do understand what they're used for, these just aren't something I'm used >> to seeing when I do my own app building. Grant it, I've only dabbled in >> producing anything resembling redistributable packages, and I certainly >> don't know what the standard procedure is for Sun teams. I'm trying to >> determine if there is any need for definition on these files, i.e. should >> they be versioned? If these files are to become first class citizens, just >> like a .h file or a .so, should we at least have something describing them, >> and how to use them? Just like with jar files, it seems a bit short sited >> to just let these artifacts be delivered without any attempt to define both >> production and consumption in view of stability. In this particular case >> we've pretty much marked the whole shooting match as volatile, so it's >> probably moot, I admit. I don't want to get into a "not this case" >> position, so I'll only suggest to the team to slap a version number in the >> .pc file name (now and in the future) and conclude my comments on this case. > > *.pc files are intended for, and used by, pkg-config. The pkg-config > mechanism is widely known, has already been described. > > Each particular component implementation explicitly defines the > version of its own pkg-config files. > > Why would explicit versioning be necessary for pkg-config *.pc files ? For the simultaneous existence of multiple, incompatible versions of a library? Gtk was provided as a good example earlier. -- Shawn Walker From stefan.teleman@gmail.com Fri Jul 31 17:58:33 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n710wWJS028890 for ; Fri, 31 Jul 2009 17:58:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n710wRQx011531; Sat, 1 Aug 2009 08:58:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNO00M07APG6Y00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Jul 2009 17:58:28 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNO009J3APFSR20@nwk-avmta-1.sfbay.Sun.COM>; Fri, 31 Jul 2009 17:58:28 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n710wRj9003078; Sat, 01 Aug 2009 00:58:27 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay44i.sun.com with ESMTP id BT-MMP-436741; Sat, 01 Aug 2009 00:58:21 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-32384277; Sat, 01 Aug 2009 00:58:18 +0000 (Z) Received: from mail-vw0-f201.google.com ([209.85.212.201] [209.85.212.201]) by relay4i.sun.com with ESMTP id BT-MMP-9377374; Sat, 01 Aug 2009 00:58:17 +0000 (Z) Received: by vws39 with SMTP id 39so350327vws.17 for ; Fri, 31 Jul 2009 17:58:10 -0700 (PDT) Received: by 10.220.94.129 with SMTP id z1mr3538275vcm.39.1249088290419; Fri, 31 Jul 2009 17:58:10 -0700 (PDT) Date: Fri, 31 Jul 2009 20:58:10 -0400 From: Stefan Teleman Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A735EA6.1060902@opensolaris.org> To: Shawn Walker Cc: Desktop Discuss , LSARC-ext@sun.com, Alan Coopersmith Message-id: <1ccb59a20907311758y674df44xf349ffbe738fbf4d@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yCuUfbUGrlat4krfDhwUu0H4gs4W7mhgYRc+toCUBpc=; b=m/exzaN7bfGwGX2uW6KgesNzfJ/IJXMWDHBjy5iA3v/qMzJY6E+K2uZvzIDE+pXLpb YlUD2/Z2JLhTT61FarPcH3Cuoy/liP7wbE81RhbwGM35qq4uZB1/m1v1oAe1Otw2nDn8 B4OZ/sjqGLh5+aJeRibzx0ou8fwziNJgs4V/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TYowsFCDocGIP28B1bMU2O/agUXDZGzepOOG3WOdye7Wb+MpYmWLvtLwLcXN3Bb8Xr sxeBuoQzuIec15neDK07CArGvm7cBXkYIZ+DJ5zypYxbeIBV+Ey9S/rPmLqkjFZZERTr f0Rc3AD45b236Bc+chU+nQ/WYEZFS//+M6pY4= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 3.098sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> <1ccb59a20907311315h7d188ea0pcacf06c5ff234785@mail.gmail.com> <4A735EA6.1060902@opensolaris.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n710wWJS028890 Status: RO Content-Length: 1088 On Fri, Jul 31, 2009 at 17:14, Shawn Walker wrote: > For the simultaneous existence of multiple, incompatible versions of a > library?  Gtk was provided as a good example earlier. i don't remember us ever providing more than one version of libgtk+-2.x.so at any time. i always though we had a pretty strict rule about "only one of each", and if we ever had a documented need for having simultaneous and incompatible versions of the same shared library component, we accomplished this artifact via physical object location + interface stability classification, and not via versioning of the pkg-config *.pc files. and in Brian's example, he explicitly stated that he is proposing installation of conflicting components in different physical filesystem locations, and *NOT* the versioning versioning of pkg-config files. if you plan on versioning pkg-config *.pc files, you will diverge from upstream, ./configure will break, and you will have created a lot of useless work for no real benefit. --Stefan -- Stefan Teleman KDE e.V. stefan.teleman@gmail.com From swalker@opensolaris.org Fri Jul 31 18:04:36 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7114Z1Q029330 for ; Fri, 31 Jul 2009 18:04:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7114SAI006318; Sat, 1 Aug 2009 02:04:33 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNO00C01AZKNH00@brm-avmta-1.central.sun.com>; Fri, 31 Jul 2009 19:04:32 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNO0046TAZJ9Z30@brm-avmta-1.central.sun.com>; Fri, 31 Jul 2009 19:04:31 -0600 (MDT) Received: from [10.7.250.188] (punchin-client-10-7-250-188.SFBay.Sun.COM [10.7.250.188]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n7114T6P665404; Fri, 31 Jul 2009 18:04:30 -0700 (PDT) Date: Fri, 31 Jul 2009 20:04:29 -0500 From: Shawn Walker Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <1ccb59a20907311758y674df44xf349ffbe738fbf4d@mail.gmail.com> To: Stefan Teleman Cc: Desktop Discuss , LSARC-ext@sun.com, Alan Coopersmith Message-id: <4A73949D.5060009@opensolaris.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> <1ccb59a20907311315h7d188ea0pcacf06c5ff234785@mail.gmail.com> <4A735EA6.1060902@opensolaris.org> <1ccb59a20907311758y674df44xf349ffbe738fbf4d@mail.gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 993 Stefan Teleman wrote: > On Fri, Jul 31, 2009 at 17:14, Shawn Walker wrote: > >> For the simultaneous existence of multiple, incompatible versions of a >> library? Gtk was provided as a good example earlier. > > i don't remember us ever providing more than one version of > libgtk+-2.x.so at any time. i always though we had a pretty strict > rule about "only one of each", and if we ever had a documented need > for having simultaneous and incompatible versions of the same shared > library component, we accomplished this artifact via physical object > location + interface stability classification, and not via versioning > of the pkg-config *.pc files. Not quite: basename file usr/lib/pkgconfig/gtk+-2.0.pc pkg:/SUNWgtk2@0.5.11-0.118 basename file usr/sfw/lib/pkgconfig/gtk+.pc pkg:/SUNWGtk@1.2.10-0.118 While those are in different directories, I've seen Linux distributions distribute them in the same directory. Cheers, -- Shawn Walker From stefan.teleman@sun.com Fri Jul 31 18:38:57 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n711cuBN000680 for ; Fri, 31 Jul 2009 18:38:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n711coK3002234 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@Sun.COM>; Sat, 1 Aug 2009 09:38:55 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNO00G05CKSHT00@brm-avmta-1.central.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Fri, 31 Jul 2009 19:38:52 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNO004WSCKS9T50@brm-avmta-1.central.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Fri, 31 Jul 2009 19:38:52 -0600 (MDT) Received: from [10.7.250.14] (punchin-client-10-7-250-14.SFBay.Sun.COM [10.7.250.14]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n711coUC668887; Fri, 31 Jul 2009 18:38:50 -0700 (PDT) Date: Fri, 31 Jul 2009 21:38:49 -0400 From: Stefan Teleman Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A73949D.5060009@opensolaris.org> To: Shawn Walker Cc: Stefan Teleman , Desktop Discuss , LSARC-ext@sun.com Reply-to: stefan.teleman@sun.com Message-id: <4A739CA9.8070807@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> <1ccb59a20907311315h7d188ea0pcacf06c5ff234785@mail.gmail.com> <4A735EA6.1060902@opensolaris.org> <1ccb59a20907311758y674df44xf349ffbe738fbf4d@mail.gmail.com> <4A73949D.5060009@opensolaris.org> User-Agent: Thunderbird 2.0.0.19 (X11/20090218) Status: RO Content-Length: 1063 Shawn Walker wrote: > Stefan Teleman wrote: >> On Fri, Jul 31, 2009 at 17:14, Shawn Walker >> wrote: >> >>> For the simultaneous existence of multiple, incompatible versions of a >>> library? Gtk was provided as a good example earlier. >> >> i don't remember us ever providing more than one version of >> libgtk+-2.x.so at any time. i always though we had a pretty strict >> rule about "only one of each", and if we ever had a documented need >> for having simultaneous and incompatible versions of the same shared >> library component, we accomplished this artifact via physical object >> location + interface stability classification, and not via versioning >> of the pkg-config *.pc files. > > Not quite: > > basename file usr/lib/pkgconfig/gtk+-2.0.pc > pkg:/SUNWgtk2@0.5.11-0.118 > > basename file usr/sfw/lib/pkgconfig/gtk+.pc > pkg:/SUNWGtk@1.2.10-0.118 *Not* the same component. Not interchangeable. No linker confusion possible. --Stefan -- Stefan Teleman Sun Microsystems, Inc. stefan.teleman@Sun.COM From Alan.Coopersmith@Sun.COM Fri Jul 31 18:48:42 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n711mglx000776 for ; Fri, 31 Jul 2009 18:48:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n711mfPe004768 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 31 Jul 2009 18:48:41 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNO00301D158100@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 18:48:41 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNO009RZD15X070@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 18:48:41 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n711mfB8000437 for ; Fri, 31 Jul 2009 18:48:41 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNO00900CZM5A00@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 31 Jul 2009 18:48:41 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNO004RID14OU10@fe-sfbay-09.sun.com>; Fri, 31 Jul 2009 18:48:41 -0700 (PDT) Date: Fri, 31 Jul 2009 18:48:40 -0700 From: Alan Coopersmith Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A739CA9.8070807@Sun.COM> Sender: Alan.Coopersmith@Sun.COM To: Stefan.Teleman@Sun.COM Cc: Shawn Walker , Stefan Teleman , Desktop Discuss , LSARC-ext@Sun.COM Message-id: <4A739EF8.2020605@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> <1ccb59a20907311315h7d188ea0pcacf06c5ff234785@mail.gmail.com> <4A735EA6.1060902@opensolaris.org> <1ccb59a20907311758y674df44xf349ffbe738fbf4d@mail.gmail.com> <4A73949D.5060009@opensolaris.org> <4A739CA9.8070807@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1145 Stefan Teleman wrote: > Shawn Walker wrote: >> Stefan Teleman wrote: >>> On Fri, Jul 31, 2009 at 17:14, Shawn Walker >>> wrote: >>> >>>> For the simultaneous existence of multiple, incompatible versions of a >>>> library? Gtk was provided as a good example earlier. >>> >>> i don't remember us ever providing more than one version of >>> libgtk+-2.x.so at any time. >> >> Not quite: >> >> basename file usr/lib/pkgconfig/gtk+-2.0.pc >> pkg:/SUNWgtk2@0.5.11-0.118 >> >> basename file usr/sfw/lib/pkgconfig/gtk+.pc >> pkg:/SUNWGtk@1.2.10-0.118 > > *Not* the same component. Not interchangeable. No linker confusion > possible. Exactly. You only want versions in the *.pc file name to distinguish between two versions that are not compatible/interchangable, and it's only useful when they're set by the upstream project so all the projects that depend on them use the versioned names, as happened in the gtk case. You are in 100% violent agreement with what Shawn & I have been saying. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Darren.Moffat@Sun.COM Sat Aug 1 02:42:57 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n719gvnF014411 for ; Sat, 1 Aug 2009 02:42:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n719guGF013727 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 1 Aug 2009 02:42:56 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNO00D01YZK5F00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Sat, 01 Aug 2009 02:42:56 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNO000ZYYZJ1L40@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Sat, 01 Aug 2009 02:42:56 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n719gtV0020351 for ; Sat, 01 Aug 2009 09:42:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNO00300YT9D500@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Sat, 01 Aug 2009 10:42:44 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNO00CNVYZ7TC30@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Sat, 01 Aug 2009 10:42:43 +0100 (BST) Date: Sat, 01 Aug 2009 10:42:41 +0100 From: Darren J Moffat Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A731F7C.5020009@gmail.com> Sender: Darren.Moffat@Sun.COM To: Mark Martin Cc: Alan Coopersmith , Jerry Tan , Desktop Discuss , LSARC-ext@Sun.COM Message-id: <4A740E11.6000707@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A71DDE4.9030704@gmail.com> <4A726103.6010001@sun.com> <4A7302EE.8090700@gmail.com> <4A731114.2040505@sun.com> <4A731F7C.5020009@gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 1304 Mark Martin wrote: > Alan Coopersmith wrote: >> Mark Martin wrote: >> >>> Well for good or bad, I've noticed .pc files before, questioned them, >>> and the teams have simply removed them. >> >> You sure you're not confusing those with .la files? libtool-generated >> .la files should not be delivered, but .pc files are used by pkg-config >> so that packages with dependencies can determine what flags to use for >> building and linking. >> >> > Nah, I meant ".pc" files. I should correct myself, though. They > weren't removed -- instead the stability on those particular artifacts > went from Uncommitted -> Cons. Private. > http://arc.opensolaris.org/caselog/LSARC/2008/782/mail The name of the .pc file should have the same stability level as the library - maybe higher but certainly not less. The content of the file should be Volatile because it can (and will in some cases) change from invocation to invocation. It is Volatile rather than "Not an Interface" because it is intended to be consumed programatically, the format is fixed by pkg-config(1) but the actual output for any given .pc file varies depending on versions and what arguments were passed to pkg-config(1). As for versioning the version information is held inside the .pc file. -- Darren J Moffat From Jerry.Tan@Sun.COM Mon Aug 3 00:47:43 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n737lgGn001318 for ; Mon, 3 Aug 2009 00:47:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n737lgfq046620 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 3 Aug 2009 01:47:42 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNS00I01IZHWL00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 03 Aug 2009 01:47:41 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNS00B16IZGQ5F0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 03 Aug 2009 01:47:41 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n737ld0a008592 for ; Mon, 03 Aug 2009 07:47:39 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNS00C00IXJHX00@mail-apac.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 03 Aug 2009 15:47:39 +0800 (SGT) Received: from [129.158.217.247] ([unknown] [129.158.217.247]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNS000T6IZEVQ80@mail-apac.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 03 Aug 2009 15:47:39 +0800 (SGT) Date: Mon, 03 Aug 2009 15:47:58 +0800 From: Jerry Tan Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A72A087.6010103@sun.com> Sender: Jerry.Tan@Sun.COM To: James.Walker@Sun.COM Cc: Brian Cameron , LSARC-ext@Sun.COM, Desktop Discuss Message-id: <4A76962E.7020505@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_rHsZk6NS1McgoG1GfYz9ZA)" X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A72A087.6010103@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 9510 This is a multi-part message in MIME format. --Boundary_(ID_rHsZk6NS1McgoG1GfYz9ZA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Thanks. Please see attachment for updated version. >>> 4.5. Interfaces: >>> >>> Exported Interface >>> >>> Interface Classification Comments >>> ----------------------------- -------------- >>> ---------------------- >>> SUNWraptor Uncommitted Package name >>> SUNWraptor-devel Uncommitted Package name >>> /usr/bin/rapper Volatile parser utility >>> /usr/bin/raptor-config Volatile config utility >>> /usr/lib/libraptor.so.1 Volatile library >>> /usr/share/man/man1/rapper.1 Volatile man page >>> /usr/share/man/man1/raptor-config.1 >>> Volatile man page >>> /usr/share/man/man3/libraptor.3 Volatile man page >>> /usr/lib/pkgconfig/raptor.pc Volatile pc file >>> /usr/include/raptor.h Volatile Header file >>> /usr/share/gtk-doc/html/raptor Volatile help file > > Some comments: > > 1. Man pages aren't interfaces and shouldn't be included here. > 2. Documentation isn't an interface and shouldn't be include here. > 3. Individual include files don't need to be specified. > 4. Package classifications should match interface classifications. > 5. Library symlink should be provided. > > Here's what I end up with: > > Interface Classification Comments > ----------------------------- -------------- ------------------ > SUNWraptor Volatile Package name > SUNWraptor-devel Volatile Package name > /usr/bin/rapper Volatile parser utility > /usr/bin/raptor-config Volatile config utility > /usr/lib/libraptor.so Volatile library symlink > /usr/lib/libraptor.so.1 Volatile library > /usr/lib/pkgconfig/raptor.pc Volatile pc file > /usr/include/ Volatile Header files > > Also, it would be good for the desktop community to evaluate the current > strategy of only delivering 64bit libraries as needed. It's normally > easier for engineers to produce both archs at the time of initial > putback then later, and we are seeing more and more interest in > community members wanting to produce 64bit ready desktops. Because of > this, "as needed" strategy it creates a barrier. If you are concerned > about space, you could include the 64bit libraries only in the devel > packages for now. > > Cheers, > Jim > _______________________________________________ > desktop-discuss mailing list > desktop-discuss@opensolaris.org --Boundary_(ID_rHsZk6NS1McgoG1GfYz9ZA) Content-type: text/plain; name=onepage-raptor.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=onepage-raptor.txt Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Raptor 1.4.19 1.2. Name of Document Author/Supplier: Author: Jerry Tan Sponsor: Brian Cameron 1.3. Date of This Document: 07/21/09 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: robert.odea@sun.com 1.4.4. The name of your business unit: OpenSolaris Desktop 1.5. Email Aliases: 1.5.1. Responsible Manager: harry.lu@sun.com 1.5.2. Responsible Engineer: jerry.tan@sun.com 1.5.3. Marketing Manager: glynn.foster@sun.com 1.5.4. Interest List: desktop-discuss@opensolaris.org 2. Project Summary 2.1. Project Description: Raptor is a free software C library that provides a set of parsers and serializers that generate Resource Description Framework (RDF) triples by parsing syntaxes or serialize the triples into a syntax. 4. Technical Description: 4.1. Details: The Raptor library provides a high-level interface to a set of parsers and serializers that generate Resource Description Framework (RDF) triples by parsing syntaxes or serialize the triples into syntaxes. The supported parsing syntaxes include RDF/XML, N-Triples, Turtle, TRiG, RSS tag soup (including all RSS and Atoms), GRDDL, RDFa and the serializing syntaxes include RDF/XML (3 varieties), N-Triples, Turtle, RSS 1.0, Atom 1.0, GraphViz DOT and RDF/JSON. The RDF/XML parser can use libxml XML parsers for providing the SAX event stream. The library functions are arranged in an object-oriented style with constructors, destructors and method calls. The statements and error messages are delivered via callback functions. Raptor contains a URI-reference parsing and resolving (not retrieval) class (raptor_uri) sufficient for dealing with URI-references inside RDF. This functionality is modular and can be transparently replaced with another existing and compatible URI implementation. It also provides a URI-retrieval class (raptor_www) for wrapping existing library such as libxml2 or BSD libfetch that provides full or partial retrieval of data from URIs and an I/O stream abstraction (raptor_iostream) for supportin serializing to a variety of outputs. Raptor uses Unicode strings for RDF literals and URIs and preserves them throughout the library. It uses the UTF-8 encoding of Unicode at the API for passing in or returning Unicode strings. It is intended that the preservation of Unicode for URIs will support Internationalized Resource Identifiers (IRIs) which are still under development and standardisation. A typical C programe that use raptor may look like this #include raptor_init(); raptor_parser *p=raptor_new_parser("rdfxml"); raptor_set_statement_handler(p,NULL,print_triples); raptor_uri *file_uri=raptor_new_uri("http://example.org/"); raptor_parse_file(p,file_uri,base_uri); raptor_parse_uri(p,uri,NULL); raptor_free_parser(p); raptor_free_uri(file_uri); raptor_finish(); 4.2. Bug/RFE Number(s): 6859024 4.3. In Scope: See above. 4.4. Out of Scope: See above. 4.5. Interfaces: Exported Interface Interface Classification Comments ----------------------------- -------------- ---------------------- SUNWraptor Uncommitted Package name SUNWraptor-devel Uncommitted Package name /usr/bin/rapper Volatile parser utility /usr/bin/raptor-config Volatile config utility /usr/lib/libraptor.so.1 Volatile library /usr/lib/libraptor.so Volatile library symlink /usr/lib/{adm64 |sparcv9}/libraptor.so.1 Volatile 64bit library /usr/lib/{amd64 |sparcv9}/libraptor.so Volatile 64bit library symlink /usr/lib/pkgconfig/raptor.pc Uncommitted pc file /usr/lib/{amd64 |sparcv9}/pkgconfig/raptor.pc Uncommitted 64bit pc file Imported Interface Interface Classification ARC case Comment -------- --------------- ---------- ------------------------------- XSLT Uncommitted PSARC/2002/244 XML2 Committed PSARC/2008/032 4.6. Doc Impact: Help docs and man page 4.7. Admin/Config Impact: None. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: The OpenSolaris Desktop team and the G11N are working together to evaluate and provide I18N/L10N support. 4.10. Packaging & Delivery: Adds two new packages: Package Cluster Comment ------------------ ------------ ---------- SUNWraptor SUNW(gnapps) base package for libraries SUNWraptor-devel SUNW(gnapps) dev pkg for raptor 4.11. Security Impact: None 4.12. Dependencies: Refer to Imported Interface table. 5. Reference Documents: [1] RDF http://www.w3.org/TR/rdf-concepts/ http://www.w3.org/TR/rdf-syntax-grammar/ http://www.w3.org/2001/sw/RDFCore/ http://www.w3.org/TR/rdf-testcases/#ntriples http://www.dajobe.org/2004/01/turtle/ [2] raptor homepage: http://librdf.org/raptor/ [3] Related ARC Cases: PSARC/2002/244 Using XSLT and libxslt in Solaris PSARC/2008/032 libxml2 upgrade to 2.6.31 PSARC/2001/175 Using XML and libxml in Solaris --Boundary_(ID_rHsZk6NS1McgoG1GfYz9ZA)-- From oboril.lukas@gmail.com Mon Aug 3 01:59:55 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n738xsUn002681 for ; Mon, 3 Aug 2009 01:59:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n738xlS6004079; Mon, 3 Aug 2009 09:59:51 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNS00305MBQ3600@brm-avmta-1.central.sun.com>; Mon, 03 Aug 2009 02:59:50 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNS0016WMBQCH10@brm-avmta-1.central.sun.com>; Mon, 03 Aug 2009 02:59:50 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n738xnOk022523; Mon, 03 Aug 2009 08:59:49 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay43i.sun.com with ESMTP id BT-MMP-1633946; Mon, 03 Aug 2009 08:59:49 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-36024828; Mon, 03 Aug 2009 08:59:45 +0000 (Z) Received: from mail-fx0-f207.google.com ([209.85.220.207] [209.85.220.207]) by relay4i.sun.com with ESMTP id BT-MMP-122169; Mon, 03 Aug 2009 08:59:45 +0000 (Z) Received: by fxm3 with SMTP id 3so150908fxm.8 for ; Mon, 03 Aug 2009 01:58:54 -0700 (PDT) Received: by 10.223.126.66 with SMTP id b2mr2207755fas.3.1249289934095; Mon, 03 Aug 2009 01:58:54 -0700 (PDT) Date: Mon, 03 Aug 2009 10:58:34 +0200 From: Lukas Oboril Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A72B056.8040301@sun.com> To: Jerry Tan Cc: Jan Hnatek , Brian Cameron , LSARC-ext@sun.com, Desktop Discuss Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ytpwEiOKCzeTxJfyv22DIkaalfyheRscvc80a7eC7UU=; b=Tsgf6KeuagF4ENubkmZ3qV2ve6tN5q8+DSPEw9vCWW92ubFNtq2u9zrQTUsEHdX8Xk A2+znvlrd1jn8ICBTNko878fFjY6XemqsMsEiz2eOH4qhSa8WCm9W2cbWQ3S5laSur8H 57vBFPpsye3s/NjsERI/DQe8B/U9322I5sor8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=WdsYO+/na6bg3soTPKds4/n3SkTSRy8E4xos1qn1mJDyBnCF1Zp1Druj4NHK/CAIHL MdVJyJqFsdTjjNvYWg21V9d/DnqE2Syd5GueeTisodPmfPWDK9jaV0awVwVlaUFu+spK 1wAZA6trm8cpM9I3SWh3EQtPBFkBs04hJeERg= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 3.333sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A70DBD1.2030901@sun.com> <4A725760.5010102@sun.com> <4A72A1DF.10302@sun.com> <4A72B056.8040301@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n738xsUn002681 Status: RO Content-Length: 8884 Jan, Jerry thank you Luc On Fri, Jul 31, 2009 at 10:50 AM, Jerry Tan wrote: > HI, Jan. > > I will add 64bit version for it. > > > Jan Hnatek : >> >> Hi Jerry, >> >> please include the 64bit libraries too. >> >> For example the redland and soprano libraries >> in the KDE project depend on raptor and it would >> be impossible/problematic to switch to using >> system-delivered raptor libraries. >> >> Regards, >> hnhn >> >> Jerry Tan wrote: >>> >>> Hi, Lukas, >>> >>> because the only application that use raptor is tracker new version, >>> it is a 32bit application. >>> so we don't build 64bit binary for raptor. >>> >>> If we got a request that some 64bit application use it, >>> we will release 64bit library for it. >>> >>> thanks. >>> >>> >>>> Brian, >>>> >>>> I do not see 64bit version of library. >>>> >>>> >>>> Luc >>>> >>>> On Thu, Jul 30, 2009 at 1:31 AM, Brian Cameron >>>> wrote: >>>> >>>>> >>>>> I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will >>>>> timeout on August 12th.  See attached onepager. >>>>> >>>>> Brian >>>>> >>>>> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >>>>> Copyright 2007 Sun Microsystems >>>>> >>>>> 1. Introduction >>>>>  1.1. Project/Component Working Name: >>>>> >>>>>       Raptor  1.4.19 >>>>> >>>>>  1.2. Name of Document Author/Supplier: >>>>> >>>>>       Author:  Jerry Tan >>>>>       Sponsor: Brian Cameron >>>>> >>>>>  1.3. Date of This Document: >>>>> >>>>>       07/21/09 >>>>> >>>>>  1.4. Name of Major Document Customer(s)/Consumer(s): >>>>> >>>>>     1.4.1. The PAC or CPT you expect to review your project: >>>>> >>>>>            Solaris PAC >>>>> >>>>>     1.4.2. The ARC(s) you expect to review your project: >>>>> >>>>>            LSARC >>>>> >>>>>     1.4.3. The Director/VP who is "Sponsoring" this project: >>>>> >>>>>            robert.odea@sun.com >>>>> >>>>>     1.4.4. The name of your business unit: >>>>> >>>>>            OpenSolaris Desktop >>>>> >>>>>  1.5. Email Aliases: >>>>> >>>>>     1.5.1. Responsible Manager: >>>>> >>>>>            harry.lu@sun.com >>>>> >>>>>     1.5.2. Responsible Engineer: >>>>> >>>>>            jerry.tan@sun.com >>>>> >>>>>     1.5.3. Marketing Manager: >>>>> >>>>>            glynn.foster@sun.com >>>>> >>>>>     1.5.4. Interest List: >>>>> >>>>>            desktop-discuss@opensolaris.org >>>>> >>>>> 2. Project Summary >>>>> >>>>>  2.1. Project Description: >>>>> >>>>>       Raptor is a free software C library that provides a set of >>>>> parsers >>>>>  and >>>>>       serializers that generate Resource Description Framework (RDF) >>>>>  triples >>>>>       by parsing syntaxes or serialize the triples into a syntax. >>>>> >>>>> 4. Technical Description: >>>>> >>>>>   4.1. Details: >>>>> >>>>>       The Raptor library provides a high-level interface to a set of >>>>> parsers >>>>>       and serializers that generate Resource Description Framework >>>>> (RDF) >>>>>       triples by parsing syntaxes or serialize the triples into >>>>> syntaxes. >>>>> >>>>>       The supported parsing syntaxes include RDF/XML, N-Triples, >>>>> Turtle, >>>>> TRiG, >>>>>       RSS tag soup  (including all RSS and Atoms), GRDDL, RDFa and the >>>>>       serializing syntaxes include RDF/XML (3 varieties), N-Triples, >>>>> Turtle, >>>>>       RSS 1.0, Atom 1.0, GraphViz DOT and RDF/JSON. The RDF/XML parser >>>>> can >>>>>       use libxml XML parsers  for providing the SAX event stream. The >>>>> library >>>>>       functions are arranged in an object-oriented style with >>>>> constructors, >>>>>       destructors and method  calls. The statements and error messages >>>>> are >>>>>       delivered via callback functions. >>>>> >>>>>       Raptor contains a URI-reference parsing and resolving (not >>>>> retrieval) >>>>>       class (raptor_uri)  sufficient for dealing with URI-references >>>>> inside >>>>>       RDF.  This functionality is modular and can be transparently >>>>> replaced >>>>>       with another existing and compatible URI implementation. >>>>> >>>>>       It also provides a URI-retrieval class (raptor_www) for wrapping >>>>>       existing  library such as libxml2 or BSD libfetch that provides >>>>> full >>>>>       or partial retrieval of data from URIs and an I/O stream >>>>> abstraction >>>>>       (raptor_iostream) for supportin serializing to a variety of >>>>> outputs. >>>>> >>>>>       Raptor uses Unicode strings for RDF literals and URIs and >>>>> preserves >>>>>       them throughout the library. It uses the UTF-8 encoding of >>>>> Unicode >>>>>       at the API for passing in or returning Unicode strings. It is >>>>> intended >>>>>       that the preservation of Unicode for URIs will support >>>>> Internationalized >>>>>       Resource Identifiers (IRIs) which are still under development >>>>>       and standardisation. >>>>> >>>>>       A typical C programe that use raptor may look like this >>>>> >>>>>       #include >>>>> >>>>>       raptor_init(); >>>>>       raptor_parser *p=raptor_new_parser("rdfxml"); >>>>>       raptor_set_statement_handler(p,NULL,print_triples); >>>>>       raptor_uri *file_uri=raptor_new_uri("http://example.org/"); >>>>>       raptor_parse_file(p,file_uri,base_uri); >>>>>       raptor_parse_uri(p,uri,NULL); >>>>>       raptor_free_parser(p); >>>>>       raptor_free_uri(file_uri); >>>>>       raptor_finish(); >>>>> >>>>> >>>>>   4.2. Bug/RFE Number(s): >>>>> >>>>>        6859024 >>>>> >>>>>   4.3. In Scope: >>>>> >>>>>        See above. >>>>> >>>>>   4.4. Out of Scope: >>>>> >>>>>        See above. >>>>> >>>>>   4.5. Interfaces: >>>>> >>>>>        Exported  Interface >>>>> >>>>>   Interface                          Classification         Comments >>>>>   -----------------------------     -------------- >>>>>  ---------------------- >>>>>   SUNWraptor                        Uncommitted     Package name >>>>>   SUNWraptor-devel                  Uncommitted     Package name >>>>>   /usr/bin/rapper                   Volatile        parser utility >>>>>   /usr/bin/raptor-config            Volatile        config utility >>>>>   /usr/lib/libraptor.so.1           Volatile        library >>>>>   /usr/share/man/man1/rapper.1      Volatile        man page >>>>>   /usr/share/man/man1/raptor-config.1 >>>>>                                     Volatile        man page >>>>>   /usr/share/man/man3/libraptor.3   Volatile        man page >>>>>   /usr/lib/pkgconfig/raptor.pc      Volatile        pc file >>>>>   /usr/include/raptor.h             Volatile        Header file >>>>>   /usr/share/gtk-doc/html/raptor    Volatile        help file >>>>> >>>>>         Imported  Interface >>>>> >>>>>   Interface  Classification    ARC case  Comment >>>>>   --------   --------------- ---------- ------------------------------- >>>>>   XSLT       Uncommitted       PSARC/2002/244 >>>>>   XML2       Committed         PSARC/2008/032 >>>>> >>>>> >>>>>   4.6. Doc Impact: >>>>> >>>>>        Help docs and man page >>>>> >>>>>   4.7. Admin/Config Impact: >>>>> >>>>>        None. >>>>> >>>>>   4.8. HA Impact: >>>>> >>>>>        None. >>>>> >>>>>   4.9. I18N/L10N Impact: >>>>> >>>>>        The OpenSolaris Desktop team and the G11N are working together >>>>> to >>>>>        evaluate and  provide I18N/L10N support. >>>>> >>>>>   4.10. Packaging & Delivery: >>>>> >>>>>         Adds two new packages: >>>>>         Package               Cluster                  Comment >>>>>         ------------------     ------------   ---------- >>>>>         SUNWraptor             SUNW(gnapps)   base package for >>>>> libraries >>>>>         SUNWraptor-devel       SUNW(gnapps)   dev pkg for raptor >>>>> >>>>>   4.11. Security Impact: >>>>> >>>>>         None >>>>> >>>>>   4.12. Dependencies: >>>>> >>>>>         Refer to Imported Interface table. >>>>> >>>>> >>>>> 5. Reference Documents: >>>>> >>>>>    [1] RDF >>>>>        http://www.w3.org/TR/rdf-concepts/ >>>>>        http://www.w3.org/TR/rdf-syntax-grammar/ >>>>>        http://www.w3.org/2001/sw/RDFCore/ >>>>>        http://www.w3.org/TR/rdf-testcases/#ntriples >>>>>        http://www.dajobe.org/2004/01/turtle/ >>>>> >>>>>    [2] raptor homepage: >>>>>        http://librdf.org/raptor/ >>>>> >>>>>    [3] Related ARC Cases: >>>>> >>>>>        PSARC/2002/244  Using XSLT and libxslt in Solaris >>>>>        PSARC/2008/032  libxml2 upgrade to 2.6.31 >>>>>        PSARC/2001/175  Using XML and libxml in Solaris >>>>> >>>>> >>>>> _______________________________________________ >>>>> desktop-discuss mailing list >>>>> desktop-discuss@opensolaris.org >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >> > > -- Lukas 'Luc' Oboril IRC nickname: luc^ at freenode When dealing with people, let us remember we are not dealing with creatures of logic. We are dealing with creatures of emotions, creatures bristling with prejudices and motivated by pride and vanity. Dale Carnegie From Brian.Cameron@sun.com Mon Aug 3 11:58:19 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n73IwID3021168 for ; Mon, 3 Aug 2009 11:58:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n73IwGaG005277 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 4 Aug 2009 02:58:17 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNT00907E127R00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 03 Aug 2009 11:58:14 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNT002O5E11N060@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 03 Aug 2009 11:58:13 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n73IwDxP013347 for ; Mon, 03 Aug 2009 18:58:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNT00300C52AO00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 03 Aug 2009 12:58:13 -0600 (MDT) Received: from [129.153.250.188] ([unknown] [129.153.250.188]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNT0005FE0TT6E0@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 03 Aug 2009 12:58:05 -0600 (MDT) Date: Mon, 03 Aug 2009 13:58:20 -0500 From: Brian Cameron Subject: Re: [desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A76962E.7020505@sun.com> Sender: Brian.Cameron@sun.com To: Jerry Tan Cc: James.Walker@sun.com, LSARC-ext@sun.com, Desktop Discuss Message-id: <4A77334C.3000204@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> <4A72A087.6010103@sun.com> <4A76962E.7020505@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090622) Status: RO Content-Length: 2885 Jerry: I updated the materials in the case directory, with the updated interface table. Thanks, Brian > Please see attachment for updated version. > > > >>>> 4.5. Interfaces: >>>> >>>> Exported Interface >>>> >>>> Interface Classification Comments >>>> ----------------------------- -------------- >>>> ---------------------- >>>> SUNWraptor Uncommitted Package name >>>> SUNWraptor-devel Uncommitted Package name >>>> /usr/bin/rapper Volatile parser utility >>>> /usr/bin/raptor-config Volatile config utility >>>> /usr/lib/libraptor.so.1 Volatile library >>>> /usr/share/man/man1/rapper.1 Volatile man page >>>> /usr/share/man/man1/raptor-config.1 >>>> Volatile man page >>>> /usr/share/man/man3/libraptor.3 Volatile man page >>>> /usr/lib/pkgconfig/raptor.pc Volatile pc file >>>> /usr/include/raptor.h Volatile Header file >>>> /usr/share/gtk-doc/html/raptor Volatile help file >> >> Some comments: >> >> 1. Man pages aren't interfaces and shouldn't be included here. >> 2. Documentation isn't an interface and shouldn't be include here. >> 3. Individual include files don't need to be specified. >> 4. Package classifications should match interface classifications. >> 5. Library symlink should be provided. >> >> Here's what I end up with: >> >> Interface Classification Comments >> ----------------------------- -------------- ------------------ >> SUNWraptor Volatile Package name >> SUNWraptor-devel Volatile Package name >> /usr/bin/rapper Volatile parser utility >> /usr/bin/raptor-config Volatile config utility >> /usr/lib/libraptor.so Volatile library symlink >> /usr/lib/libraptor.so.1 Volatile library >> /usr/lib/pkgconfig/raptor.pc Volatile pc file >> /usr/include/ Volatile Header files >> >> Also, it would be good for the desktop community to evaluate the current >> strategy of only delivering 64bit libraries as needed. It's normally >> easier for engineers to produce both archs at the time of initial >> putback then later, and we are seeing more and more interest in >> community members wanting to produce 64bit ready desktops. Because of >> this, "as needed" strategy it creates a barrier. If you are concerned >> about space, you could include the 64bit libraries only in the devel >> packages for now. >> >> Cheers, >> Jim >> _______________________________________________ >> desktop-discuss mailing list >> desktop-discuss@opensolaris.org > From Brian.Cameron@Sun.COM Tue Aug 4 12:10:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n74JApL4008321 for ; Tue, 4 Aug 2009 12:10:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n74JAmq4005613 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 4 Aug 2009 20:10:51 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNV00G0B9A1ME00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 04 Aug 2009 12:10:49 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNV0023S9A0GWF0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 04 Aug 2009 12:10:48 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n74JAmje025719 for ; Tue, 04 Aug 2009 19:10:48 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNV00C008QHQX00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 04 Aug 2009 13:10:48 -0600 (MDT) Received: from [129.153.250.126] ([unknown] [129.153.250.126]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNV007RP99ZCAD0@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 04 Aug 2009 13:10:48 -0600 (MDT) Date: Tue, 04 Aug 2009 14:11:04 -0500 From: Brian Cameron Subject: Re: Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009] In-reply-to: <4A70DBD1.2030901@sun.com> Sender: Brian.Cameron@Sun.COM To: Brian Cameron Cc: LSARC-ext@Sun.COM, Desktop Discuss Message-id: <4A7887C8.9020006@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A70DBD1.2030901@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090622) Status: RO Content-Length: 426 Note that this case was approved at today's LSARC meeting. Brian Brian Cameron wrote: > > I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will > timeout on August 12th. See attached onepager. > > Brian > > > ------------------------------------------------------------------------ > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org