<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.os.solaris.opencsw.maintainers">
    <title>gmane.os.solaris.opencsw.maintainers</title>
    <link>http://blog.gmane.org/gmane.os.solaris.opencsw.maintainers</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10903"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10901"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10895"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10881"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10872"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10867"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10863"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10860"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10856"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10846"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10845"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10831"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10827"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10820"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10819"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10815"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10813"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10809"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10801"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10792"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10903">
    <title>mgar question: repackage for platforms modulation</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10903</link>
    <description>&lt;pre&gt;I'm "playing" with checkpkg overrides and must re-do the packaging for all
the platforms quite a few times.

Using "replatforms" is the rough equivalent of "clean platforms" which
means that everything is redone each time; quite longish for a big package
such as Emacs with 3 specific modulations in addition to the platform
ones.

Using "repackage" does the job for only the current platform which is not
enough when inter-architecture issues are tickling checkpkg...

I there a shorter and more complete way of doing this[1]?

TIA

[1] i.e., "repackage" for all platforms in one step
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

&lt;/pre&gt;</description>
    <dc:creator>pfelecan-RJLij68YbUJAfugRpC6u6w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-25T14:06:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10901">
    <title>cannot set overrides for Emacs: please review</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10901</link>
    <description>&lt;pre&gt;I'm approaching the end of the GARification for Emacs. However I'm stuck
with 5 overrides which are not taken into account eventough they are
explicited in the recipe.

- log:

RUNTIME_DEP_PKGS_CSWemacs-common += CSWemacscommon
If any of the reported errors were false positives, you can override them
pasting the lines below to the GAR recipe.
CHECKPKG_OVERRIDES_CSWemacs +=
file-with-bad-content|/usr/local|root/opt/csw/bin/emacs-athena
CHECKPKG_OVERRIDES_CSWemacs +=
file-with-bad-content|/usr/share|root/opt/csw/bin/emacs-athena
CHECKPKG_OVERRIDES_CSWemacs-gtk +=
file-with-bad-content|/usr/local|root/opt/csw/bin/emacs-gtk
CHECKPKG_OVERRIDES_CSWemacs-gtk +=
file-with-bad-content|/usr/share|root/opt/csw/bin/emacs-gtk

- Makefile:

CHECKPKG_OVERRIDES_CSWemacs-common+=missing-dependency|CSWemacscommon

CHECKPKG_OVERRIDES_CSWemacs+=file-with-bad-content|/usr/local|root/opt/csw/bin/emacs-athena
CHECKPKG_OVERRIDES_CSWemacs+=file-with-bad-content|/usr
/share|root/opt/csw/bin/emacs-athena

CHECKPKG_OVERRIDES_CSWemacs-gtk+=file-with-bad-content|/usr/local|root/opt/csw/bin/emacs-gtk
CHECKPKG_OVERRIDES_CSWemacs-gtk+=file-with-bad-content|/usr/share|root/opt/csw/bin/emacs-gtk

- buildfarm logs

  emacs_common:
http://buildfarm.opencsw.org/pkgdb/srv4/0213609a932f87a2bd387ae4312ef420/
  emacs:       
http://buildfarm.opencsw.org/pkgdb/srv4/e70220797cdeac77550d274c96b73e26/
  emacs_gtk:   
http://buildfarm.opencsw.org/pkgdb/srv4/ed88fc2a74985edc60ccec19cfdda9c6/

TIA



_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

&lt;/pre&gt;</description>
    <dc:creator>pfelecan-RJLij68YbUJAfugRpC6u6w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-25T13:59:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10895">
    <title>Problem with csw-upload-pkg?</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10895</link>
    <description>&lt;pre&gt;I have some weird problem with checkpkg. I'm trying to upload the bind
set of packages which I have done many times before, they were just
built in GAR passing checkpkg checks.

bonivart&amp;lt; at &amp;gt;login[build.2012-05-22]$ pwd
/home/bonivart/staging/build.2012-05-22
bonivart&amp;lt; at &amp;gt;login[build.2012-05-22]$ ls
bind-9.8.3,REV=2012.05.22-SunOS5.9-i386-CSW.pkg.gz
bind-9.8.3,REV=2012.05.22-SunOS5.9-sparc-CSW.pkg.gz
bind_chroot-9.8.3,REV=2012.05.22-SunOS5.9-all-CSW.pkg.gz
bind_dev-9.8.3,REV=2012.05.22-SunOS5.9-i386-CSW.pkg.gz
bind_dev-9.8.3,REV=2012.05.22-SunOS5.9-sparc-CSW.pkg.gz
bind_utils-9.8.3,REV=2012.05.22-SunOS5.9-i386-CSW.pkg.gz
bind_utils-9.8.3,REV=2012.05.22-SunOS5.9-sparc-CSW.pkg.gz
libbind-9.8.3,REV=2012.05.22-SunOS5.9-i386-CSW.pkg.gz
libbind-9.8.3,REV=2012.05.22-SunOS5.9-sparc-CSW.pkg.gz
bonivart&amp;lt; at &amp;gt;login[build.2012-05-22]$ csw-upload-pkg *
Processing 9 file(s). Please wait.
Uploading 'bind-9.8.3,REV=2012.05.22-SunOS5.9-i386-CSW.pkg.gz'
ERROR:root:File metadata was not found in the database.  This happens
when the package you're trying to upload was never unpacked and
imported into the database.  To fix the problem, run checkpkg against
your package and try importing again.
Traceback (most recent call last):
  File "/home/bonivart/opencsw/.buildsys/v2/bin/csw-upload-pkg", line
627, in &amp;lt;module&amp;gt;
    uploader.Upload()
  File "/home/bonivart/opencsw/.buildsys/v2/bin/csw-upload-pkg", line
173, in Upload
    raise DataError("file_metadata is empty: %s" % repr(file_metadata))
__main__.DataError: file_metadata is empty: None

Is it the actual upload that is the problem because it fails quickly
and the traceback mentions it?

/peter
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

&lt;/pre&gt;</description>
    <dc:creator>Peter Bonivart</dc:creator>
    <dc:date>2012-05-25T08:06:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10881">
    <title>checkpkg problem under Solaris 11 ?</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10881</link>
    <description>&lt;pre&gt;Hi,

I have a lot of file-collision error when I build the openssl package under
Solaris 11:

[...]
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/share/man/man3/BIO_s_socket.3|CSWlibssl-dev|CSWossldevel
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/include/openssl/pqueue.h|CSWlibssl-dev|CSWossldevel
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/lib/pkgconfig/libcrypto.pc|CSWlibssl-dev|CSWossldevel
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/share/man/man3/BN_bn2mpi.3|CSWlibssl-dev|CSWossldevel
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/share/man/man3/BN_sub_word.3|CSWlibssl-dev|CSWossldevel
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/share/man/man3/X509_NAME_add_entry_by_NID.3|CSWlibssl-dev|CSWossldevel
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/share/man/man3/UI_construct_prompt.3|CSWlibssl-dev|CSWossldevel
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/share/man/man3/EVP_PKEY_set1_RSA.3|CSWlibssl-dev|CSWossldevel
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/share/man/man3/DES_cfb_encrypt.3|CSWlibssl-dev|CSWossldevel
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/share/man/man3/BUF_strdup.3|CSWlibssl-dev|CSWossldevel
CHECKPKG_OVERRIDES_CSWlibssl-dev +=
file-collision|/opt/csw/share/man/man3/MD5_Update.3|CSWlibssl-dev|CSWossldevel
[...]

However CSWossldevel is now a stub package and doesn't contain these files
anymore.
Is there something wrong in the database ?


Yann
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.&lt;/pre&gt;</description>
    <dc:creator>Yann Rouillard</dc:creator>
    <dc:date>2012-05-24T20:20:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10872">
    <title>T4 crypto support in openssl 1.0</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10872</link>
    <description>&lt;pre&gt;Hi everyone,

I successfully compiled Solaris 11 openssl 1.0 packages with T4 crypto
support:

$ openssl engine -t
(t4) SPARC T4 engine support (no T4)
     [ available ]
(dynamic) Dynamic engine loading support
     [ unavailable ]
(pkcs11) PKCS #11 engine support
     [ available ]

Unfortunately, I don't have access to sparc hardware with sparc t4
microprocessor to test that the crypto acceleration works correctly.
Does anyone have such hardware available ?

The packages are available in my experimental repository:
http://buildfarm.opencsw.org/experimental.html#yann

Thanks in advance,

Yann
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.&lt;/pre&gt;</description>
    <dc:creator>Yann Rouillard</dc:creator>
    <dc:date>2012-05-23T21:00:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10867">
    <title>review requested for Emacs GARification</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10867</link>
    <description>&lt;pre&gt;I think that I advanced quite well in my struggle of GARification for
Emacs. However, I'm stuck in the post-install modulation... Can a
knowledgeable maintainer review the recipe and help me out for this issue
and point out the other issues that he encounters.

FYI, the significant changes are in
http://gar.svn.sourceforge.net/viewvc/gar?view=revision&amp;amp;revision=18093

TIA
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

&lt;/pre&gt;</description>
    <dc:creator>pfelecan-RJLij68YbUJAfugRpC6u6w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-23T14:04:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10863">
    <title>mail form submission for retired maintainers</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10863</link>
    <description>&lt;pre&gt;
Hi All,

I'm about to implement some proper retirement scripts that will close
down mail accounts, etc for retired maintainers.  This means that
we'll need to direct mail from our web forms to an alternate mailbox
so we don't bounce mail.

The mail originates from an unpredictable From address so we need an
open list for them.  Should we abuse the pkgrequests&amp;lt; at &amp;gt; list for this or
spawn something new?  I don't have a strong preference either way.  My
only concern is that we get the contact from people that go to the
trouble of filling out the form[1].

Thanks
-Ben

[1] The forms still need to be captcha'd.  If nobody else jumps on
    this, I'll try to get it done soon.
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

&lt;/pre&gt;</description>
    <dc:creator>Ben Walton</dc:creator>
    <dc:date>2012-05-23T00:31:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10860">
    <title>pkgutil cycle in dependency</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10860</link>
    <description>&lt;pre&gt;How can I investigate this problem:

bash-4.2# pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/qt4 -x cas -i CSWqt4-gxx-doc
=&amp;gt; Fetching new catalog and descriptions (http://buildfarm.opencsw.org/opencsw/experimental/qt4/i386/5.10) if available ...
==&amp;gt; 20 packages loaded from /var/opt/csw/pkgutil/catalog.buildfarm.opencsw.org_opencsw_experimental_qt4_i386_5.10
=&amp;gt; Fetching new catalog and descriptions (http://mirror.opencsw.org/opencsw/unstable/i386/5.10) if available ...
==&amp;gt; 3471 packages loaded from /var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.10
Solving needed dependencies ...
Solving dependency order ...
Loop protection limit (100000 iterations) hit. There's probably a
cyclic dependency in the catalog.
Do you want to continue anyway? ([y],n) n


Thanks
--
Carsten Grzemba
Tel.:   +49 3677 64740
Mobil: +49 171 9749479
Fax::   +49 3677 6474111
Email: carsten.grzemba&amp;lt; at &amp;gt;contac-dt.de
contac Datentechnik GmbH
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.&lt;/pre&gt;</description>
    <dc:creator>Carsten Grzemba</dc:creator>
    <dc:date>2012-05-22T12:15:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10856">
    <title>board elections 2012</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10856</link>
    <description>&lt;pre&gt;
Hi All,

This is (quite a bit) overdue so it's time to get it rolling.  The 1
year term of the board is up and we should elect a new board.  To get
things started, I created a wiki page at
http://wiki.opencsw.org/boardelection2012 where you can nominate
yourself for a place on the ballot.  For examples of what people wrote
in their self nominations last time, please see
http://wiki.opencsw.org/boardelection.

It would be nice to have lots of people step forward for a role on the
board.  The only requirement for nomination is that you're a member of
OpenCSW.  To be a member, you simply need to send mail to board&amp;lt; at &amp;gt;
indicating that you'd like full membership status.  The barrier to
being granted full membership status is that you're an active
maintainer of at least one package.

We can leave the nomination page open for a few weeks and evaluate
what that ballot would look like then.  If there isn't enough sign-up
interest, I'll stir the pot some more. :)

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

&lt;/pre&gt;</description>
    <dc:creator>Ben Walton</dc:creator>
    <dc:date>2012-05-17T14:45:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10846">
    <title>advice on custom manifests</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10846</link>
    <description>&lt;pre&gt;
Hi All,

I'm looking at the exim package and want to improve it so that it can
be installed without user prompts and also to fix a few other warts.

The user prompts all surround the replacement of the system binaries
such as sendmail and mailq.  For the sendmail replacement, putting a
service dependency on sendmail-client is sufficient to avoid any need
to replace the binary.

So the question is: Is there a best practice that we're using when we
ship a custom manifest or should I just take the auto-generated one
and add the extra dependency?

My plan for replacing mailq is to write a little wrapper script and
setup an alternative handler so that it can play nice with Peter's
sendmail and Juraj's postfix if they want to ship those too.  It would
rely on PATH for precedence over the system version, but I think
that's way nicer than moving the system version out of the way and I
sort of expect that people would have /opt/csw/bin high in precedence
anyway.  (I'm definitely open to better solutions though if someone
has one.)

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

&lt;/pre&gt;</description>
    <dc:creator>Ben Walton</dc:creator>
    <dc:date>2012-05-12T22:03:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10845">
    <title>At least Openssl 1.0 !</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10845</link>
    <description>&lt;pre&gt;Unbelievable ! Openssl 1.0 packages are close to be on their way to the
OpenCSW repository.

You will find openssl 1.0.1c packages in my experimental repository:
    yes | pkgrm CSWopenssl-utils CSWlibssl-dev
    pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/yann -i
openssl_utils libssl_dev libssl1_0_0

Before releasing them, I would welcome additional testing from other
members and in particular, build tests with these new libraries.
I already rebuild my own packages (openssh, vsftpd, lftp) to ensure there's
no build and execution problem.

I updated the PKCS11 patch so these libraries should still take advantage
of sparc crypto capabilites if you enable the pkcs11 engine.
I am working on integrating the T4 and aesni crypto acceleration support
but it would be in a later build (and it seems solaris 11 specific).


Some notes concerning the migration:

  - libssl_dev will be replaced with the 1.0.1c version so once it will be
installed on the buildfram, all subsequent will be linked with libssl 1.0
    and it will be not possible anymore to build against libssl 0.9.8
    There doesn't seem to be API incompatibility and the same choice has
been done by other distro, but this is the reason why I would
    welcome additional build tests so I can be certain.


  - libssl 0.9.8 will of course still be there (and maintained), it can be
installed alongside libssl 1.0.
    Starting with libssl 1.0, the SSL engines directory has been moved in a
versioned directory so we don't have filenames clash.

    However, within a month or two, I will start to fill bug against
packages linked with libssl 0.9.8 to ask for a rebuild with libssl 1.0.


  - libssl relies on system-wide hash symbolic links located in
/etc/opt/csw/ssl/certs to verify certificates (provided by the
ca_certificates packages under OpenCSW).
 Unfortunately, the hash system has changed between 0.9.8 and 1.0, the
ca_certificates package and the c_rehash script (used to generate the
symlinks) have been
 modified to always generate the old and the new hash symlinks. There is
clash risk but it should be low.
 - I don't plan on updating the openssl package so that it depends on
libssl 1.0. This package is a legacy of a time where there was a unique
package containing libraries, development files and the openssl tools. Packages
should no longer depend on this package and I prefer to drop it the day we
will remove libssl 0.9.8 from the repository.


Thanks in advance for any comment and feedback,

Yann
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.&lt;/pre&gt;</description>
    <dc:creator>Yann Rouillard</dc:creator>
    <dc:date>2012-05-12T17:50:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10831">
    <title>Problem with pkgutil automatic installation</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10831</link>
    <description>&lt;pre&gt;I recently made the conversion from pkg-get to pkgutil.  Now when I do
a full update (/opt/csw/bin/pkgutil -u), I am first prompted:

    ## packages to fetch. Do you want to continue? ([y],n,auto)

and then for each package I am repeatedly prompted:

    Do you want to remove this package? [y,n,?,q]

and if dependency checks fail, I get:

    Do you want to continue with the removal of this package [y,n,?,q]


Here is the content of /var/opt/csw/pkgutil/admin (mode 644):

    action=nocheck
    basedir=default
    conflict=nocheck
    idepend=nocheck
    instance=overwrite
    mail=
    partial=nocheck
    rdepend=nocheck
    runlevel=nocheck
    setuid=nocheck
    space=nocheck

This was probably migrated forward from pkg-get, or else it is the default
admin file installed by pkgutil, as I have not modified this file in years.

Any suggestion as to why I am not getting fully automated installs and
updates?

Thanks.
&lt;/pre&gt;</description>
    <dc:creator>Jeffery Small</dc:creator>
    <dc:date>2012-05-04T23:39:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10827">
    <title>seg fault and stack size issue?</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10827</link>
    <description>&lt;pre&gt;


I'm trying to run the repro process from reSIProcate

The startup phase fails with a seg fault

I couldn't find a specific fault in the code, even compiling with +w2
hasn't suggested anything wrong.  It is just failing to create some
vectors in a constructor, and I think the seg fault may be caused by
filling the stack.  Can anyone suggest how I increase the stack size or
test this problem more thoroughly when building with SunPro tools?

pmap reports a 64k stack size:

pmap core
core 'core' of 23190:
/home/daniel/ws/resip-trunk.git/repro/.libs/repro /home/daniel/repro1.
00010000       8K r-x--  /home/daniel/ws/resip-trunk.git/repro/.libs/repro
00020000       8K rwx--  /home/daniel/ws/resip-trunk.git/repro/.libs/repro
00022000      56K rwx--
00030000    2432K rwx--    [ heap ]
FD600000    1408K r-x--  /opt/csw/lib/libcrypto.so.0.9.8
FD760000      24K r-x--  /opt/csw/lib/libcrypto.so.0.9.8
FD774000      88K rwx--  /opt/csw/lib/libcrypto.so.0.9.8
FD78A000       8K rwx--  /opt/csw/lib/libcrypto.so.0.9.8
FD7C0000      64K rwx--
FD7E0000      64K rwx--
FD800000    1216K r-x--  /lib/libc.so.1

...

FEBB0000     192K r-x--  /lib/ld.so.1
FEBE0000      16K r-x--  /lib/ld.so.1
FEBF0000       8K rwx--
FEBF4000       8K rwx--  /lib/ld.so.1
FEBF6000       8K rwx--  /lib/ld.so.1
FEBFC000       8K rwx--
FFBF0000      64K rwx--    [ stack ]
 total     22736K



and this is the stack:

core 'core' of 23190:
/home/daniel/ws/resip-trunk.git/repro/.libs/repro /home/daniel/repro1.
 fd856e18 _smalloc (fe2b7ca8, 0, d9660, fd856f94, f227a048, fd93929c) + ac
 fd856e70 malloc   (1, 1, d95ac, febd2a04, fd9303d8, fd93a5a0) + 4c
 fe356fc0 __1c2n6FI_pv_ (1, 0, 0, 15d74, fe36cd10, 7ffffc00) + 28
 fe9b79ec __1cDstdJallocator4nFresipEData__Iallocate6MIpv_3_ (ffbfecab,
0, 0, 20, febf4380, 0) + 2c
 fe9b6e48
__1cDstdTallocator_interface4n0AJallocator4nFresipEData___n0C__Iallocate6MIpn0C__4_
(ffbfecab, 0, 0, 0, febf4380, 0) + 28
 fe9b6b1c __1cDstdGvector4nFresipEData_n0AJallocator4n0C____2t5B6Mrk2_v_
(ffbfee18, ffbfedac, ffbfedab, ffbfed7d, febf4380, 0) + ac
 fdf33d80
__1cFresipRMessageFilterRule2t5B6MnDstdGvector4n0AEData_n0CJallocator4n0D_____n0BNHostpartTypes_n0CGvector4n0ALMethodTypes_n0CJallocator4n0H_____3_v_
(ffbfede4, ffbfedd4, 0, ffbfedc0, ffbfedac, 0) + 90
 fdf35bf8
__1cFresipPTransactionUser2t5B6Mn0BWTransactionTermination_n0BVConnectionTermination_n0BOKeepAlivePongs__v_
(28be90, 1, 0, 0, fd9303d8, fd93a5a0) + 1a8
 fe53bc9c __1cFresipSDialogUsageManager2t5B6Mrn0AISipStack_b_v_ (28be60,
831f0, 0, 15d74, fe36cd10, 28be60) + 7c
 fea3ece8 __1cFreproLReproRunnerYcreateDialogUsageManager6M_v_
(ffbffa04, ffbff6c0, fdbea248, 0, fdbe461c, ffbff6b8) + 5f0
 fea3b2ec __1cFreproLReproRunnerDrun6Mippc_b_ (ffbffa04, 2, ffbffb34,
fe356db0, fd7e8cc0, f) + 7c4
 00011644 main     (2, ffbffb34, ffbffb40, 21c00, fd7e8c40, 0) + 12c
 00011050 _start   (0, 0, 0, 0, 0, 0) + 108



and the constructor in question is very minimal, the vectors are created
by default argument values:

https://svn.resiprocate.org/viewsvn/resiprocate/main/resip/stack/MessageFilterRule.hxx?revision=8707&amp;amp;view=markup


_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

&lt;/pre&gt;</description>
    <dc:creator>Daniel Pocock</dc:creator>
    <dc:date>2012-05-04T09:47:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10820">
    <title>accessing the Web mail for OpenCSW</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10820</link>
    <description>&lt;pre&gt;I'm trying to access the mailing server at https://mail.opencsw.org/
without success: my user and/or password is incorrect. Is there a kind
soul which can tell me what's the procedure to obtain the correct
credentials to access this resource.

TIA
&lt;/pre&gt;</description>
    <dc:creator>Peter FELECAN</dc:creator>
    <dc:date>2012-05-02T18:37:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10819">
    <title>[checkpkg] Shared library related bugfix pushed</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10819</link>
    <description>&lt;pre&gt;I have pushed a bugfix today, which removes a problem with shared
library checking. The bug was causing checkpkg to classify binaries as
non-binaries, which in turn broke shared library checking functions,
including package split suggestions. It is fixed now in the
repository, please update your subversion clients. To get the fixed
code, run:

mgar up-buildsys

The fixed code will correctly index new packages, but since the bug
was in the indexing part, there is a number of packages that have
inaccurate metadata in the database.

Sorry for the inconvenience!

Maciej

[1] http://wiki.opencsw.org/gar-wrapper
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

&lt;/pre&gt;</description>
    <dc:creator>Maciej (Matchek) Bliziński</dc:creator>
    <dc:date>2012-04-30T13:04:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10815">
    <title>Solaris 10 revision suppport?</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10815</link>
    <description>&lt;pre&gt;What is the CSW support for the revisions of Solaris 10?

This page:
    http://www.opencsw.org/manual/for-administrators/introduction.html

says "Solaris 10 is fully supported." which isn't true as CSWorbit2
2.14.19,REV=2011.12.08 doesn't work with Solaris 10U4.  Either we
consider this a bug and fix it or CSW is only supported on certain
revisions of Solaris 10, either way I'm happy but if taking the latter it
would help to explain this better, that is at a minimum change the above
web page.



** A Failure **

$ soffice
ld.so.1: soffice.bin: fatal: libresolv.so.2: version `SUNW_2.2.2' not
found (required by file /opt/csw/lib/sparcv8/libORBit-2.so.0)
ld.so.1: soffice.bin: fatal: libresolv.so.2: open failed: No such file or
directory
ld.so.1: soffice.bin: fatal: relocation error: file
/opt/csw/openoffice.org/program/../basis-link/program/ucpgvfs1.uno.so:
symbol gnome_vfs_initialized: referenced symbol not found
Killed


This problem is not limited to CSWorbit2 but potentially affects any
linkage to versioned symbols present on the build machines but not on the
client's OS.




** Explanation **

libresolv.so.2 has versioned symbols and libORBit-2.so.0 requires
version SUNW_2.2.2 which is not present in Solaris 10U4.  U6 works.  I
don't have quick access to U5, maybe someone will please check U5.

Check the versions, examples run on a new system:

$ /usr/ccs/bin/elfdump -v /opt/csw/lib/libORBit-2.so.0.1.0

Version Needed Section:  .SUNW_version
            file                        version
            libpthread.so.1             SUNW_1.2
            libresolv.so.2              SUNW_2.2.2
                                        SUNWprivate_2.1
            libnsl.so.1                 SUNW_1.7
                                        SUNWprivate_1.1
            libsocket.so.1              SUNW_1.4
            libc.so.1                   SUNW_0.7



$ /usr/ccs/bin/elfdump -v /lib/libresolv.so.2

Version Definition Section:  .SUNW_version
     index  version                     dependency
       [1]  libresolv.so.2                                   [ BASE ]
       [2]  SUNW_2.2.2                  SUNW_2.2.1
       [3]  SUNW_2.2.1                  SUNW_2.2
       [4]  SUNW_2.2                    SUNW_2.1
       [5]  SUNW_2.1
       [6]  SUNWprivate_2.2             SUNWprivate_2.1
       [7]  SUNWprivate_2.1

...





** Workaround **

Use old orbit:
http://csw.informatik.uni-erlangen.de/oldpkgs/allpkgs/orbit2-2.14.19,REV
=2011.06.10-SunOS5.9-sparc-CSW.pkg.gz




** Solutions **

1. Link with a mapfile and select a universal version.  This means users
don't take advantage of whatever a new version brings.


2. Link twice, once normally and then with a mapfile and do something
clever based on the OS.


3. Build on a low rev machine.  Probably not acceptable, eg, cc 12.3
might not run.


4. Clients update Solaris.  For this to be acceptable do the following:
 + Change support statement in the user guide
 + packages that need specific updates or patches use baulking
   checkinstall scripts.
 + (suggestion) pkgutil to check the OS update in addition to
   checkinstall.   checkinstall is the correct place but pkgutil can
   provides early detections and prevent a failed partial update.




James.
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

&lt;/pre&gt;</description>
    <dc:creator>James Lee</dc:creator>
    <dc:date>2012-04-30T11:21:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10813">
    <title>OBSOLETED_BY_ not work?</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10813</link>
    <description>&lt;pre&gt;Hi,

/opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9 --architecture i386 d9b1f8d5af903ced92e4fbf24f5de2bb

reports many errors of this kind:

CHECKPKG_OVERRIDES_CSWpoppler-data += file-collision|/opt/csw/share/poppler/cMap/Adobe-Japan1/RKSJ-H|CSWpoppler-data|CSWpopplerdata

CSWpoppler-data replaces CSWpopplerdata

the recipe contains:

OBSOLETED_BY_CSWpoppler-data = CSWpopplerdata

What's wrong?
--
Carsten Grzemba
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.&lt;/pre&gt;</description>
    <dc:creator>Carsten Grzemba</dc:creator>
    <dc:date>2012-04-30T09:19:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10809">
    <title>Fwd: [csw-users] CSWsyslogng version mismatch</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10809</link>
    <description>&lt;pre&gt;
There is some sort of breakage here...the old version is still in the
5.11 catalogs.

Maciej?

Thanks
-Ben

--- Begin forwarded message from dennis jenkins ---
From: dennis jenkins &amp;lt;dennis.jenkins.75&amp;lt; at &amp;gt;gmail.com&amp;gt;
To: users &amp;lt;users&amp;lt; at &amp;gt;lists.opencsw.org&amp;gt;
Date: Fri, 27 Apr 2012 11:42:49 -0400
Subject: [csw-users] CSWsyslogng version mismatch

Hello.

   My system is Solaris 11 (11/11) [1].  I wish to install CSWsyslog_ng.
"pkgutil" shows that it would install version 3.0.5,REV=2010.02.27 (over 2
years old) [2], but the OpenCSW online package index shows that it should
install 3.2.5,REV=2012.03.19 (yeah!) [3]

   I've tried both "testing" and "unstable".  I've refreshed my catalog
several times.  What am I missing?  How do I get OpenCSW to give me the
more recent syslog_ng?

   Thank you for your time.

[1]
(root&amp;lt; at &amp;gt;sol-11: &amp;lt;~&amp;gt;) # uname -a
SunOS sol-11-ai-mad-1 5.11 11.0 i86pc i386 i86pc

(root&amp;lt; at &amp;gt;sol-11: &amp;lt;~&amp;gt;) # cat /etc/release
                           Oracle Solaris 11 11/11 X86
  Copyright (c) 1983, 2011, Oracle and/or its affiliates.  All rights
reserved.
                            Assembled 18 October 2011


[2]
(root&amp;lt; at &amp;gt;sol-11: &amp;lt;~&amp;gt;) # /opt/csw/bin/pkgutil -a | grep CSWsyslogng
syslog_ng            CSWsyslogng          3.0.5,REV=2010.02.27       135.5
KB


(root&amp;lt; at &amp;gt;sol-11: &amp;lt;~&amp;gt;) # /opt/csw/bin/pkgutil --catinfo

URL             http://mirror.opencsw.org/opencsw/unstable/i386/5.11
Release         -
Creation time   2012-04-27T13:33:47Z
Number of pkgs  3453
File
/var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.11



[3] http://www.opencsw.org/packages/syslog_ng/
   Hello.

      My system is Solaris 11 (11/11) [1].  I wish to install CSWsyslog_ng. 
   "pkgutil" shows that it would install version 3.0.5,REV=2010.02.27 (over 2
   years old) [2], but the OpenCSW online package index shows that it should
   install 3.2.5,REV=2012.03.19 (yeah!) [3]

      I've tried both "testing" and "unstable".  I've refreshed my catalog
   several times.  What am I missing?  How do I get OpenCSW to give me the
   more recent syslog_ng?

      Thank you for your time.

   [1]
   (root&amp;lt; at &amp;gt;sol-11: &amp;lt;~&amp;gt;) # uname -a
   SunOS sol-11-ai-mad-1 5.11 11.0 i86pc i386 i86pc

   (root&amp;lt; at &amp;gt;sol-11: &amp;lt;~&amp;gt;) # cat /etc/release
                              Oracle Solaris 11 11/11 X86
     Copyright (c) 1983, 2011, Oracle and/or its affiliates.  All rights
   reserved.
                               Assembled 18 October 2011

   [2]
   (root&amp;lt; at &amp;gt;sol-11: &amp;lt;~&amp;gt;) # /opt/csw/bin/pkgutil -a | grep CSWsyslogng
   syslog_ng            CSWsyslogng          3.0.5,REV=2010.02.27       135.5
   KB

   (root&amp;lt; at &amp;gt;sol-11: &amp;lt;~&amp;gt;) # /opt/csw/bin/pkgutil --catinfo

   URL             [1]http://mirror.opencsw.org/opencsw/unstable/i386/5.11
   Release         -
   Creation time   2012-04-27T13:33:47Z
   Number of pkgs  3453
   File           
   /var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.11

   [3] [2]http://www.opencsw.org/packages/syslog_ng/

References

   Visible links
   1. http://mirror.opencsw.org/opencsw/unstable/i386/5.11
   2. http://www.opencsw.org/packages/syslog_ng/
--- End forwarded message ---
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

_______________________________________________
maintainers mailing list
maintainers&amp;lt; at &amp;gt;lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.&lt;/pre&gt;</description>
    <dc:creator>Ben Walton</dc:creator>
    <dc:date>2012-04-27T17:03:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10801">
    <title>checkpkg issues with last openssl build</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10801</link>
    <description>&lt;pre&gt;Hi everybody,

I am currently having some checkpkg problem with the last openssl build
(which contains a security fix, so quick help is welcome :) ).

CHECKPKG_OVERRIDES_CSWlibssl0-9-8 +=
bad-rpath-entry|/opt/csw/lib/sparcv8plus+vis|/tmp/pkg_0mVWKJ/CSWlibssl0-9-8/root/opt/csw/lib/sparcv8plus+vis/libcrypto.so.0.9.7
CHECKPKG_OVERRIDES_CSWlibssl0-9-8 +=
bad-rpath-entry|/opt/csw/lib/sparcv8plus+vis|/tmp/pkg_0mVWKJ/CSWlibssl0-9-8/root/opt/csw/lib/sparcv8plus+vis/libssl.so.0.9.7

I used to have an override for this one, but the temporary path
(/tmp/pkg_*) preprended now prevents it from working.
Is this some bug in the GAR system ?

* Unused Override: CSWossldevel: surplus-dependency CSWlibssl-dev
* Unused Override: CSWosslutils: archall-devel-package
* Unused Override: CSWossl: archall-devel-package
* Unused Override: CSWosslrt: archall-devel-package

These ones are automatically added by "OBSOLETED_BY" macros, I could stop
using the macro but I would rather have the macro fixed so it doesn't
trigger checkpkg warnings.

I don't know if I am missing something there but any help is welcome :)

Yann
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.&lt;/pre&gt;</description>
    <dc:creator>Yann Rouillard</dc:creator>
    <dc:date>2012-04-27T12:43:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10792">
    <title>rpath nigthmare</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10792</link>
    <description>&lt;pre&gt;Hi,

if I build netsnmp I have trouble to get useful search paths for so objects in the libs.

If I leave the '-L/opt/csw/lib -R/opt/csw/lib/$ISALIST -R/opt/csw/lib' in LDFLAGS of mgar modenv, then it builds all.

But in build python module I get the damaged search path /opt/csw/SALIST and the wrong/old libs...so.15  from /opt/csw/lib is used.

   find object=libnetsnmp.so.15; required by build/lib.solaris-2.10-i86pc-2.6/netsnmp/client_intf.so

    search 
path=/opt/csw/lib/SALIST:/opt/csw/lib:/opt/csw/lib/$ISALIST:/opt/csw/lib 
 (RPATH from file 
build/lib.solaris-2.10-i86pc-2.6/netsnmp/client_intf.so)

    trying path=/opt/csw/lib/SALIST/libnetsnmp.so.15

    trying path=/opt/csw/lib/libnetsnmp.so.15


If I remove the -L and -R from LDFLAGS from mgar modenv all builds well except for one perlmodule perl/agent/default_store. There I get the strange search path

   find object=libnetsnmp.so.25; required by blib/arch/auto/NetSNMP/agent/default_store/default_store.so
    search path=/home/cgrzemba/opencsw/netsnmp/trunk/work/build-isa-pentium_pro/net-snmp-5.6.1.1/perl/agent/default_store/../../../snmplib/.libs:/usr/lib
 (RPATH from file blib/arch/auto/NetSNMP/agent/default_store/default_store.so)
    trying path=/home/cgrzemba/opencsw/netsnmp/trunk/work/build-isa-pentium_pro/net-snmp-5.6.1.1/perl/agent/default_store/../../../snmplib/.libs/libnetsnmp.so.25
        libnetsnmp.so.25 =&amp;gt;      /home/cgrzemba/opencsw/netsnmp/trunk/work/build-isa-pentium_pro/net-snmp-5.6.1.1/perl/agent/default_store/../../../snmplib/.libs/libnetsnmp.so.25

Any hints?
--
Carsten Grzemba
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.&lt;/pre&gt;</description>
    <dc:creator>Carsten Grzemba</dc:creator>
    <dc:date>2012-04-26T08:54:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10789">
    <title>new pkg old libs?</title>
    <link>http://comments.gmane.org/gmane.os.solaris.opencsw.maintainers/10789</link>
    <description>&lt;pre&gt;Hi,

is it still a valid way to provide old libs via a tarball file like files/old_libs_s.tar.gz, even though there are now separate lib packages?
The old package containig the lib will now obsoleted by the base package.

e.g: 
the active version CSWnetsnmp contains the whole stuff

the new version is splited in CSWnetsnmp, CSWlibnetsnmp25, ...
and there are old lib's used by other packages lib...so.10 and lib..so.15

--
Carsten Grzemba
Tel.:   +49 3677 64740
Mobil: +49 171 9749479
Fax::   +49 3677 6474111
Email: carsten.grzemba&amp;lt; at &amp;gt;contac-dt.de
contac Datentechnik GmbH
_______________________________________________
maintainers mailing list
maintainers-ZwoEplunGu0I44EcYr5p3di2O/JbrIOy&amp;lt; at &amp;gt;public.gmane.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.&lt;/pre&gt;</description>
    <dc:creator>Carsten Grzemba</dc:creator>
    <dc:date>2012-04-25T12:20:38</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.os.solaris.opencsw.maintainers">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.os.solaris.opencsw.maintainers</link>
  </textinput>
</rdf:RDF>

