From bwalton at opencsw.org  Thu Apr  1 04:47:30 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 31 Mar 2010 22:47:30 -0400
Subject: [csw-maintainers] tcl/tk 8.5.8 and expect 5.43
In-Reply-To: <4BAFC95A.7000405@opencsw.org>
References: <4BAFC95A.7000405@opencsw.org>
Message-ID: <1270089868-sup-4604@pinkfloyd.chass.utoronto.ca>

Excerpts from Roger H?kansson's message of Sun Mar 28 17:25:46 -0400 2010:

> Please report any problem you encounter.

How about successes?  gitk and the ruby tk module both function with
the updated packages.  I'll try to build one or both of these packages
on testing9* in the next day or so to exercise the 8.5 versions too.

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


From pfelecan at opencsw.org  Thu Apr  1 10:09:27 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Thu, 01 Apr 2010 10:09:27 +0200
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10
	-	Intel
In-Reply-To: <4BB394FE.7070003@opencsw.org> ("Roger =?iso-8859-1?Q?H=E5kan?=
	=?iso-8859-1?Q?sson=22's?= message of
	"Wed, 31 Mar 2010 20:31:26 +0200")
References: <4BB3247C.8040104@clamav.net> <x6fx3ghe44.fsf@acm.org>
	<4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<4BB35DEC.4020805@opencsw.org> <x639zgh2vm.fsf@opencsw.org>
	<4BB37B25.2050306@opencsw.org> <x6y6h8fm2i.fsf@opencsw.org>
	<4BB3922D.3010407@opencsw.org> <x6tyrwfiue.fsf@opencsw.org>
	<4BB394FE.7070003@opencsw.org>
Message-ID: <x6pr2jfvbc.fsf@opencsw.org>

Roger H?kansson <hson at opencsw.org> writes:

> On 2010-03-31 20:26, Peter FELECAN wrote:
>
>>> Not in it self, no, but when others start using that as basis for
>>> optimizing/configuring their software things can go seriously
>>> wrong. I've seen several packages where they use the output from gcc
>>> to figure out which OS they are running and what features they can
>>> use.
>>
>> Can you give one or more examples?
>
> Nah, I tend to forget the names of software faster than you can say...
>
>> What will solve that? Why? Arguments of the arguing, please.
>
> You have already gotten some, seems enough for me.

Consequently, at this stage, I consider that there are no solid
arguments in favor of your proposition.
-- 
Peter

From phil at bolthole.com  Thu Apr  1 20:30:24 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 1 Apr 2010 11:30:24 -0700
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
References: <4BB3247C.8040104@clamav.net> <x6fx3ghe44.fsf@acm.org>
	<4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<4BB35DEC.4020805@opencsw.org>
	<C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
Message-ID: <o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>

On Wed, Mar 31, 2010 at 7:46 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>
>
> +1 from me. But it breaks the long-hated NFS-for-all.

Okay, we know - you dont like this method.
That being said, I would request that we, as a group, and you
particularly as a member of our board, refrain from making further
remarks of this type?

Okay, you dont like it. But there are still quite a few places that
share out software via NFS.
Or other methods that functional for packaging purposes, effectively
similar to it.
(eg: rsync)

To talk like this, is to insult our customers' choices. Not a good
thing at the best of times, but when the choice in this particular
case is a perfectly valid one, especially makes us look bad.

From bonivart at opencsw.org  Thu Apr  1 22:30:04 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Thu, 1 Apr 2010 22:30:04 +0200
Subject: [csw-maintainers] /testing clamav 0.96, bind 9.7.0-P1
Message-ID: <t2t625385e31004011330ld1604019hd9246647a4210c6c@mail.gmail.com>

Please help testing the new Clam Antivirus and BIND DNS packages.

You can find the packages here:
http://mirror.opencsw.org/experimental.html#bonivart.

Install with: pkgutil -t
http://mirror.opencsw.org/opencsw/experimental/bonivart -i
<catalogname>

Direct links:

http://mirror.opencsw.org/experimental/bonivart/clamav-0.96,REV=2010.04.01-SunOS5.9-sparc-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/clamav-0.96,REV=2010.04.01-SunOS5.9-i386-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/libclamav-0.96,REV=2010.04.01-SunOS5.9-i386-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/libclamav-0.96,REV=2010.04.01-SunOS5.9-sparc-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/bind-9.7.0P1,REV=2010.03.30-SunOS5.9-i386-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/bind-9.7.0P1,REV=2010.03.30-SunOS5.9-sparc-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/bind_utils-9.7.0P1,REV=2010.03.30-SunOS5.9-i386-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/bind_utils-9.7.0P1,REV=2010.03.30-SunOS5.9-sparc-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/libbind-9.7.0P1,REV=2010.03.30-SunOS5.9-i386-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/libbind-9.7.0P1,REV=2010.03.30-SunOS5.9-sparc-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/bind_chroot-9.7.0P1,REV=2010.03.30-SunOS5.9-all-CSW.pkg.gz
http://mirror.opencsw.org/experimental/bonivart/bind_devel-9.7.0P1,REV=2010.03.30-SunOS5.9-all-CSW.pkg.gz

-- 
/peter

From hson at opencsw.org  Fri Apr  2 00:21:44 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Fri, 02 Apr 2010 00:21:44 +0200
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10
 -	Intel
In-Reply-To: <o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
References: <4BB3247C.8040104@clamav.net>
	<x6fx3ghe44.fsf@acm.org>	<4BB3423C.3050401@clamav.net>	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>	<4BB35DEC.4020805@opencsw.org>	<C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
	<o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
Message-ID: <4BB51C78.4050409@opencsw.org>

On 2010-04-01 20:30, Philip Brown wrote:
> To talk like this, is to insult our customers' choices. Not a good
> thing at the best of times, but when the choice in this particular
> case is a perfectly valid one, especially makes us look bad.

Sharing /opt between OS releases can never be considered a valid 
configuration and we should not try to support such a configuration either.
Any "customer" choosing to try such setup, do it at their own risk.

Having said that, we should try to support a "one NFS share per OS 
release" configuration which is common.
(during my 20 years of working with SunOS 4/5, I've seen many 
configurations, netboot with filesystems on local disk, netboot with 
everything NFS-mounted, NFS-shared /usr... But I have never seen anyone 
try a NFS-for-all setup, there have always been different shares for 
different OS releases)

From rupert at opencsw.org  Fri Apr  2 10:33:59 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Fri, 2 Apr 2010 10:33:59 +0200
Subject: [csw-maintainers] python - illegal compiler flag ?
Message-ID: <h2p6af4271004020133n5a02effeoad8d09d3c5c89315@mail.gmail.com>

while building mercurial-1.5.1 i got the error, on both build9s, and build9x:

/opt/studio/SOS11/SUNWspro/bin/cc -G -m32 -xarch=386 -L/opt/csw/lib
-xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include
build/temp.solaris-2.9-i86pc-2.6/mercurial/parsers.o -L/opt/csw/lib
-lpython2.6 -o build/lib.solaris-2.9-i86pc-2.6/mercurial/parsers.so
cc: Warning: illegal option -m32
cc: Warning: illegal option -m32

it compiles, so the package is on testing now.

rupert

From hson at opencsw.org  Fri Apr  2 10:48:36 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Fri, 02 Apr 2010 10:48:36 +0200
Subject: [csw-maintainers] python - illegal compiler flag ?
In-Reply-To: <h2p6af4271004020133n5a02effeoad8d09d3c5c89315@mail.gmail.com>
References: <h2p6af4271004020133n5a02effeoad8d09d3c5c89315@mail.gmail.com>
Message-ID: <4BB5AF64.90903@opencsw.org>

On 2010-04-02 10:33, rupert THURNER wrote:
> while building mercurial-1.5.1 i got the error, on both build9s, and build9x:
>
> /opt/studio/SOS11/SUNWspro/bin/cc -G -m32 -xarch=386 -L/opt/csw/lib
> -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include
> build/temp.solaris-2.9-i86pc-2.6/mercurial/parsers.o -L/opt/csw/lib
> -lpython2.6 -o build/lib.solaris-2.9-i86pc-2.6/mercurial/parsers.so
> cc: Warning: illegal option -m32
> cc: Warning: illegal option -m32

The SOS11 compiler doesn't like -m32, but you should be using SOS12 
anyway...

From hson at opencsw.org  Fri Apr  2 11:30:07 2010
From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=)
Date: Fri, 02 Apr 2010 11:30:07 +0200
Subject: [csw-maintainers] 64-bit python (was evince-2.24.2 in experimental)
In-Reply-To: <ce97543b1003110107t523036afwced68e5c949e65e8@mail.gmail.com>
References: <ce97543b1003050400x153cdb36r7c98f5154905b5f1@mail.gmail.com>
	<ce97543b1003080328n740fd5c9gb281ba8ce41e22c7@mail.gmail.com>
	<ce97543b1003090004o3740fdc7i2ab86870b7dccc92@mail.gmail.com>
	<4B9614B0.7030503@cmi.univ-mrs.fr>	<ce97543b1003100045l5b0d179s8d83eba2c72896b1@mail.gmail.com>
	<ce97543b1003102345q572e1241v530d8976d7531f55@mail.gmail.com>
	<ce97543b1003102356s5a26a090iea389c91e15da163@mail.gmail.com>
	<4B989CCA.2060409@opencsw.org>	<ce97543b1003110046k12567a32ic3da53b4490716d5@mail.gmail.com>
	<4B98B139.8020001@opencsw.org>
	<ce97543b1003110107t523036afwced68e5c949e65e8@mail.gmail.com>
Message-ID: <4BB5B91F.1010107@opencsw.org>

On 2010-03-11 10:07, Maciej (Matchek) Blizinski wrote:
> On Thu, Mar 11, 2010 at 9:00 AM, Roger H?kansson<hson at opencsw.org>  wrote:
>> On 2010-03-11 09:46, Maciej (Matchek) Blizinski wrote:
>>> but lcms depends on Python, which is not, and
>>> will not, in the nearest future, be available in 64-bit.
>>
>> Why not?
>
> I've looked at it once.  Python headers do checks on certain 64-bit
> related constants, which AFAIK are set by the compiler; the assertions
> in the Python code are failing.
>
> "/opt/csw/include/python2.6/pyport.h", line 680: Error: #error
> "LONG_BIT definition appears wrong for platform (bad gcc/glibc
> config?).".
>

The problem is that you need to "merge" pyconfig.h from both 32-bit and 
64-bit and add some ifdefs to switch between them.
How/if this can be done using GAR I have no idea.

From skayser at opencsw.org  Fri Apr  2 22:26:34 2010
From: skayser at opencsw.org (Sebastian Kayser)
Date: Fri, 02 Apr 2010 22:26:34 +0200
Subject: [csw-maintainers] Mantis privileges elevated to allow for easier
	cross-package collaboration
Message-ID: <4BB652FA.2080006@opencsw.org>

Greetings,

as discussed in [1] I have finally elevated the global privileges for
all maintainers in Mantis to DEVELOPER. This means, everyone should now
be able to do everyday work on bugs (like moving or assigning) for _all_
packages, not just the ones which one specifically owns.

Questions or anything not working as expected? Please let me know.

Sebastian

[1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html

From rupert at opencsw.org  Sat Apr  3 16:03:02 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Sat, 3 Apr 2010 16:03:02 +0200
Subject: [csw-maintainers] opensolaris command more compliant - what is
	opencsw solution ?
Message-ID: <o2p6af4271004030703j6a9dfab5gab03719faeb40b39@mail.gmail.com>

hi,

the mercurial testsuite relies on which returning something non 0 in
case nothing is found. the standard solaris csh script returns 0.

the opensolaris which fixed this, see
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/which/which.csh

     53     if ( ! $?found ) then
     54         echo no $arg in $path
     55 	set exit_status = 1
     56     endif
     57 end
     58
     59 exit ${exit_status}
     60

what is the strategy we follow in opencsw in such cases?

rupert.

From bwalton at opencsw.org  Sat Apr  3 18:54:53 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 03 Apr 2010 12:54:53 -0400
Subject: [csw-maintainers] opensolaris command more compliant - what is
	opencsw solution ?
In-Reply-To: <o2p6af4271004030703j6a9dfab5gab03719faeb40b39@mail.gmail.com>
References: <o2p6af4271004030703j6a9dfab5gab03719faeb40b39@mail.gmail.com>
Message-ID: <1270313646-sup-8139@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Sat Apr 03 10:03:02 -0400 2010:

Hi Rupert,

> the mercurial testsuite relies on which returning something non 0 in
> case nothing is found. the standard solaris csh script returns 0.

The following ruby script, if placed with precedence somewhere in your
PATH during the mercurial build[1] would likely work.  It's not full
featured, but should do the trick, I think.  You'd want to then add
CSWruby as a build prerequisite too (or rewrite in perl or python,
etc).

--snip--
#!/opt/csw/bin/ruby -w
ENV['PATH'].split(':').each do |p|
  begin
    prog = File.join(p, ARGV[0])
    f = File.stat(prog)
  rescue Errno::ENOENT => e
    # file doesn't exist in this path
    # this also catches dangling symlinks...
    next
  else
    # file does exist.  is it usable?
    if f.file? and f.executable?
      puts prog
      exit 0
    end
  end
end

$stderr.puts "#{ARGV[0]} not found in #{ENV['PATH'].gsub(':', ' ')}"
exit 1
--snip--

I wasn't aware of this breakage in `which.` There is a proper which
available here: http://www.xs4all.nl/~carlo17/which/.  Looks like
Maciej was working on it already...Maciej, are there build issues with
it?

Thanks
-Ben

[1] Add the script as 'which' in your files/ directory, make it +x and
    do: PATH := $(FILEDIR):$(PATH) in your GAR recipe...this is rough,
    but should be close to what you need to make it work.
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From jeff at cjsa.com  Sun Apr  4 08:27:08 2010
From: jeff at cjsa.com (Jeffery Small)
Date: Sun, 4 Apr 2010 06:27:08 GMT
Subject: [csw-maintainers] Upgrade problems??
Message-ID: <L0C9x8.D0w@cjsa.com>

I have encountered this problem twice now and strongly believe that it is
related to doing a pkg-get upgrade operation.  The problem is that I don't
discover the actual problem until long after the upgrade procedure which I
didn't pay close attention to at the time.

The problem is that I have had some programs - notably xpdf, uninstalled
and then not reinstalled after the upgrade.  I don't notice this until I
try to use xpdf.

When I do discover this, I manually install xpdf again, and I get the
following messages:

Analysing special files...
Please see /opt/csw/share/doc/xpdf/license for license information.
WARNING: /opt/csw/bin/pdffonts <no longer a linked file>
WARNING: /opt/csw/bin/pdfimages <no longer a linked file>
WARNING: /opt/csw/bin/pdfinfo <no longer a linked file>
WARNING: /opt/csw/bin/pdftoppm <no longer a linked file>
WARNING: /opt/csw/bin/pdftops <no longer a linked file>
WARNING: /opt/csw/bin/pdftotext <no longer a linked file>

Installation of <CSWxpdf> was successful.

I remember seeing this message the last time I had to manually reinstalled
xpdf.  Are these messages normal and expected, or do they indicate a
conflict with some other package?  When I do a pkgchk -l CSWxpdf, it
reports that files like pdffonts, pdfimages, pdfinfo, pdftoppm, pdftops,
and pdftotext are referenced by packages CSWpoppler and CSWxpdf.  I'm gonna'
take a guess here and say that there may be a conflict between these two
packages and that may somehow be responsible for CSWxpdf getting trashed -
possibly when CSWpoppler is upgraded?

Any thoughts or comments?

Regards,
-- 
Jeff

C. Jeffery Small           CJSA LLC                       206-232-3338
jeff at cjsa.com              7000 E Mercer Way, Mercer Island, WA  98040


From hson at opencsw.org  Sun Apr  4 09:18:33 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Sun, 04 Apr 2010 09:18:33 +0200
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <L0C9x8.D0w@cjsa.com>
References: <L0C9x8.D0w@cjsa.com>
Message-ID: <4BB83D49.20806@opencsw.org>

On 2010-04-04 08:27, Jeffery Small wrote:
>When I do a pkgchk -l CSWxpdf, it
> reports that files like pdffonts, pdfimages, pdfinfo, pdftoppm, pdftops,
> and pdftotext are referenced by packages CSWpoppler and CSWxpdf.  I'm gonna'
> take a guess here and say that there may be a conflict between these two
> packages and that may somehow be responsible for CSWxpdf getting trashed -
> possibly when CSWpoppler is upgraded?

Yes there is a conflict between CSWpoppler and CSWxpdf due to the fact 
that poppler is a fork of the xpdf source and they have kept the binary 
names. CSWpoppler have CSWxpdf marked as incompatible so you should not 
be able to install it by mistake, however CSWxpdf does not have 
CSWpoppler as incompatible (yet).

From bwalton at opencsw.org  Mon Apr  5 03:45:41 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 04 Apr 2010 21:45:41 -0400
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
References: <4BB3247C.8040104@clamav.net> <x6fx3ghe44.fsf@acm.org>
	<4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<4BB35DEC.4020805@opencsw.org>
	<C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
	<o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
Message-ID: <1270431512-sup-8336@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Thu Apr 01 14:30:24 -0400 2010:

> That being said, I would request that we, as a group, and you
> particularly as a member of our board, refrain from making further
> remarks of this type?

And what is a valid forum for discussing our past decisions in order
to (possibly) re-examine them?  It's perfectly legitimate, imo, to
discuss things like this on the maintainers list...if not here then
where?  Private email among a cabal of select individuals?[1][2]

> To talk like this, is to insult our customers' choices. Not a good
> thing at the best of times, but when the choice in this particular
> case is a perfectly valid one, especially makes us look bad.

It was _clearly_ not Dago's intent to insult anyone with his remarks.
Anyone that would take offense at the comment is someone that's easily
offended in general...

Thanks
-Ben

[1] No, I'm not being serious here, just pointing out that this list
    really is our only valid place for the discussion to happen.
[2] I'm also in no way proposing a private mailing list here.  Being
    open is a good thing.
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Mon Apr  5 03:48:21 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 04 Apr 2010 21:48:21 -0400
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
References: <4BB3247C.8040104@clamav.net> <x6fx3ghe44.fsf@acm.org>
	<4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
Message-ID: <1270431962-sup-7422@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Wed Mar 31 10:19:31 -0400 2010:

> I already bumped gcc4 to the latest versions and it compiles
> (although it takes a day or so), merging is tbd.

Ok, so if we ignore the isaexec issue (which exists in the current
package anyway), could we simply re-roll for sol9, add a postinstall
script that does the fixincludes ala Peter's gcc3 packages and get
something out?

A more long term solution could follow later...

Thoughts?

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


From jeff at cjsa.com  Mon Apr  5 04:05:17 2010
From: jeff at cjsa.com (Jeffery Small)
Date: Mon, 5 Apr 2010 02:05:17 GMT
Subject: [csw-maintainers] Upgrade problems??
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
Message-ID: <L0DsGt.KKM@cjsa.com>

"=?ISO-8859-1?Q?Roger_H=E5kansson?=" <hson at opencsw.org> writes:

>On 2010-04-04 08:27, Jeffery Small wrote:
>>When I do a pkgchk -l CSWxpdf, it
>> reports that files like pdffonts, pdfimages, pdfinfo, pdftoppm, pdftops,
>> and pdftotext are referenced by packages CSWpoppler and CSWxpdf.  I'm gonna'
>> take a guess here and say that there may be a conflict between these two
>> packages and that may somehow be responsible for CSWxpdf getting trashed -
>> possibly when CSWpoppler is upgraded?

>Yes there is a conflict between CSWpoppler and CSWxpdf due to the fact 
>that poppler is a fork of the xpdf source and they have kept the binary 
>names. CSWpoppler have CSWxpdf marked as incompatible so you should not 
>be able to install it by mistake, however CSWxpdf does not have 
>CSWpoppler as incompatible (yet).

CSWpoppler is a rendering library while CSWxpdf is a PDF viewer.

CSWpoppler is required for evince, gimp and claws_pdfviewer, so it is
crucial.  So how can you allow this type of incompatibility which should
make it impossible to install xpdf?  Why hasn't xpdf been fixed to rely
on CSWpoppler?  Making these packages incompatible is no solution.  I do
not understand why CSWpoppler ever got released with this incompatibility
intact?

Stuff like this makes the entire CSW tree unpredictable.  You can't have
one package simply removing another!  And I consider xpdf to be a very
valuable program.  It's 5 times faster than Adobe Reader.

Regards,
-- 
Jeff

C. Jeffery Small           CJSA LLC                       206-232-3338
jeff at cjsa.com              7000 E Mercer Way, Mercer Island, WA  98040


From hson at opencsw.org  Mon Apr  5 07:13:32 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Mon, 05 Apr 2010 07:13:32 +0200
Subject: [csw-maintainers] Mantis privileges elevated to allow for
 easier cross-package collaboration
In-Reply-To: <4BB652FA.2080006@opencsw.org>
References: <4BB652FA.2080006@opencsw.org>
Message-ID: <4BB9717C.4020006@opencsw.org>

On 2010-04-02 22:26, Sebastian Kayser wrote:
> Greetings,
>
> as discussed in [1] I have finally elevated the global privileges for
> all maintainers in Mantis to DEVELOPER. This means, everyone should now
> be able to do everyday work on bugs (like moving or assigning) for _all_
> packages, not just the ones which one specifically owns.

Weee! Great work!

From william at wbonnet.net  Mon Apr  5 11:54:37 2010
From: william at wbonnet.net (William Bonnet)
Date: Mon, 05 Apr 2010 11:54:37 +0200
Subject: [csw-maintainers] Mantis privileges elevated to allow for
 easier cross-package collaboration
In-Reply-To: <4BB652FA.2080006@opencsw.org>
References: <4BB652FA.2080006@opencsw.org>
Message-ID: <4BB9B35D.5060109@wbonnet.net>

Hi Sebastian
> as discussed in [1] I have finally elevated the global privileges for
> all maintainers in Mantis to DEVELOPER. This means, everyone should now
> be able to do everyday work on bugs (like moving or assigning) for _all_
> packages, not just the ones which one specifically owns.
>
> Questions or anything not working as expected? Please let me know.
>
> Sebastian
>
> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html
>   
Thanks

cheers
W.

-- 
William                  http://www.wbonnet.net

http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix
http://www.opencsw.org 	 Community SoftWare for Solaris
http://www.guses.org     French speaking Solaris User Group



From pfelecan at opencsw.org  Mon Apr  5 14:58:06 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Mon, 05 Apr 2010 14:58:06 +0200
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <1270431962-sup-7422@pinkfloyd.chass.utoronto.ca> (Ben Walton's
	message of "Sun, 04 Apr 2010 21:48:21 -0400")
References: <4BB3247C.8040104@clamav.net> <x6fx3ghe44.fsf@acm.org>
	<4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<1270431962-sup-7422@pinkfloyd.chass.utoronto.ca>
Message-ID: <x6aatidpk1.fsf@opencsw.org>

Ben Walton <bwalton at opencsw.org> writes:

> Excerpts from Dagobert Michelsen's message of Wed Mar 31 10:19:31 -0400 2010:
>
>> I already bumped gcc4 to the latest versions and it compiles
>> (although it takes a day or so), merging is tbd.
>
> Ok, so if we ignore the isaexec issue (which exists in the current
> package anyway), could we simply re-roll for sol9, add a postinstall
> script that does the fixincludes ala Peter's gcc3 packages and get
> something out?

> A more long term solution could follow later...

In what what you propose above is not a long term solution (at least
until a new upstream release comes out which is anyway, already the
case) ?
-- 
Peter

From pfelecan at opencsw.org  Mon Apr  5 15:02:45 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Mon, 05 Apr 2010 15:02:45 +0200
Subject: [csw-maintainers] Mantis privileges elevated to allow for
	easier cross-package collaboration
In-Reply-To: <4BB652FA.2080006@opencsw.org> (Sebastian Kayser's message of
	"Fri, 02 Apr 2010 22:26:34 +0200")
References: <4BB652FA.2080006@opencsw.org>
Message-ID: <x66346dpca.fsf@opencsw.org>

Sebastian Kayser <skayser at opencsw.org> writes:

> as discussed in [1] I have finally elevated the global privileges for
> all maintainers in Mantis to DEVELOPER. This means, everyone should now
> be able to do everyday work on bugs (like moving or assigning) for _all_
> packages, not just the ones which one specifically owns.
>
> Questions or anything not working as expected? Please let me know.
>
> Sebastian
>
> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html

And this answers to what requirement(s)?

Strangely, the assignment was not a feature available for a "developer"
in the messages that you refer but now it changes?
-- 
Peter

From bwalton at opencsw.org  Mon Apr  5 16:12:01 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 05 Apr 2010 10:12:01 -0400
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <x6aatidpk1.fsf@opencsw.org>
References: <4BB3247C.8040104@clamav.net> <x6fx3ghe44.fsf@acm.org>
	<4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<1270431962-sup-7422@pinkfloyd.chass.utoronto.ca>
	<x6aatidpk1.fsf@opencsw.org>
Message-ID: <1270476641-sup-3510@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter FELECAN's message of Mon Apr 05 08:58:06 -0400 2010:

> In what what you propose above is not a long term solution (at least
> until a new upstream release comes out which is anyway, already the
> case) ?

Well, it _could_ be a long term solution, I guess, but given that Dago
has identified other issues with the package, presumably someone will
care enough to address those too at some point...

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


From skayser at opencsw.org  Mon Apr  5 19:06:44 2010
From: skayser at opencsw.org (Sebastian Kayser)
Date: Mon, 05 Apr 2010 19:06:44 +0200
Subject: [csw-maintainers] Mantis privileges elevated to allow
 for	easier cross-package collaboration
In-Reply-To: <x66346dpca.fsf@opencsw.org>
References: <4BB652FA.2080006@opencsw.org> <x66346dpca.fsf@opencsw.org>
Message-ID: <4BBA18A4.8010809@opencsw.org>

Peter FELECAN wrote on 05.04.2010 15:02:
> Sebastian Kayser <skayser at opencsw.org> writes:
> 
>> as discussed in [1] I have finally elevated the global privileges for
>> all maintainers in Mantis to DEVELOPER. This means, everyone should now
>> be able to do everyday work on bugs (like moving or assigning) for _all_
>> packages, not just the ones which one specifically owns.
>>
>> Questions or anything not working as expected? Please let me know.
>>
>> Sebastian
>>
>> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html
> 
> And this answers to what requirement(s)?

Is this a sincere question (not quite sure, your mails seemed to have a
touch of irony/sarcasm lately)?

It just makes working on/with bugs easier for maintainers. Bugs against
orphaned packages can now be worked on before you officially
release/adopt the package. If you mis-file a bug against the wrong
package (like it happened with multiple tabs and the Mantis cookie
mechanism of tracking the currently active project) you can move it
yourself, without calling upon an administrator. In the end it gives
everyone a bit more flexibility.

> Strangely, the assignment was not a feature available for a "developer"
> in the messages that you refer but now it changes?

The key in Roger's message was "if I remember". As it stands, developers
can assign bugs out of the box, no change required.

Sebastian

From hson at opencsw.org  Mon Apr  5 19:11:41 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Mon, 05 Apr 2010 19:11:41 +0200
Subject: [csw-maintainers] Mantis privileges elevated to allow
 for	easier cross-package collaboration
In-Reply-To: <x66346dpca.fsf@opencsw.org>
References: <4BB652FA.2080006@opencsw.org> <x66346dpca.fsf@opencsw.org>
Message-ID: <4BBA19CD.40003@opencsw.org>

On 2010-04-05 15:02, Peter FELECAN wrote:
> Sebastian Kayser<skayser at opencsw.org>  writes:
>
>> as discussed in [1] I have finally elevated the global privileges for
>> all maintainers in Mantis to DEVELOPER. This means, everyone should now
>> be able to do everyday work on bugs (like moving or assigning) for _all_
>> packages, not just the ones which one specifically owns.
>>
>> Questions or anything not working as expected? Please let me know.
>>
>> Sebastian
>>
>> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html
>
> And this answers to what requirement(s)?

First of all, we have a ton of packages either orphaned or "owned" by 
absent/retired/... maintainers and if someone else starts to work on 
fixing a bug, he can't communicate with the bug reporter as its intended 
(set the status to feedback) until he has released a new package and 
becomes maintainer for the package.

Also, another problem which also relates to orphaned packages is this:
Say that you want to fix a problem in package A (which you are 
maintainer for) which depends on B which depends on C which depends on 
D. And you know that the problem is solved by upgrading/turning on a 
config-option in D so that C can autoconfig itself differently so B 
behaves diffrently which fixes the problem in A.
Mantis have a good feature where you can daisy-chain bugs so you can see 
which bug needs to be fixed first and when its fixed the next maintainer 
can move on and so on.
Without developer access the only way for the maintainer of A to achieve 
this is to report a bug on each package, mail the maintainers and ask 
them to manually chain them, and in case of orphaned packages, ask the 
admins to do it, even though the maintainer of A could do this all by 
him self if he had the correct permissions.
(Which you can do now)


> Strangely, the assignment was not a feature available for a "developer"
> in the messages that you refer but now it changes?

Well, thats my fault, I remembered wrong what privileges a "developer" 
and a "manager" has, its been a while since I ran Mantis...

From pfelecan at opencsw.org  Mon Apr  5 20:27:35 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Mon, 05 Apr 2010 20:27:35 +0200
Subject: [csw-maintainers] Mantis privileges elevated to allow
	for	easier cross-package collaboration
In-Reply-To: <4BBA18A4.8010809@opencsw.org> (Sebastian Kayser's message of
	"Mon, 05 Apr 2010 19:06:44 +0200")
References: <4BB652FA.2080006@opencsw.org> <x66346dpca.fsf@opencsw.org>
	<4BBA18A4.8010809@opencsw.org>
Message-ID: <x6y6h1bvqg.fsf@opencsw.org>

Sebastian Kayser <skayser at opencsw.org> writes:

> Peter FELECAN wrote on 05.04.2010 15:02:
>> Sebastian Kayser <skayser at opencsw.org> writes:
>> 
>>> as discussed in [1] I have finally elevated the global privileges for
>>> all maintainers in Mantis to DEVELOPER. This means, everyone should now
>>> be able to do everyday work on bugs (like moving or assigning) for _all_
>>> packages, not just the ones which one specifically owns.
>>>
>>> Questions or anything not working as expected? Please let me know.
>>>
>>> Sebastian
>>>
>>> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html
>> 
>> And this answers to what requirement(s)?
>
> Is this a sincere question (not quite sure, your mails seemed to have a
> touch of irony/sarcasm lately)?

What make you doubt my sincerity? Of course, there were irony about the
oldish releases of our beloved operating system but other than that...

> It just makes working on/with bugs easier for maintainers. Bugs against
> orphaned packages can now be worked on before you officially
> release/adopt the package. If you mis-file a bug against the wrong
> package (like it happened with multiple tabs and the Mantis cookie
> mechanism of tracking the currently active project) you can move it
> yourself, without calling upon an administrator. In the end it gives
> everyone a bit more flexibility.

That I understand.

>> Strangely, the assignment was not a feature available for a "developer"
>> in the messages that you refer but now it changes?
>
> The key in Roger's message was "if I remember". As it stands, developers
> can assign bugs out of the box, no change required.

I didn't knew that. Thank you for the answers.
-- 
Peter

From pfelecan at opencsw.org  Mon Apr  5 20:31:00 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Mon, 05 Apr 2010 20:31:00 +0200
Subject: [csw-maintainers] Mantis privileges elevated to allow
	for	easier cross-package collaboration
In-Reply-To: <4BBA19CD.40003@opencsw.org> ("Roger =?iso-8859-1?Q?H=E5kanss?=
	=?iso-8859-1?Q?on=22's?= message of
	"Mon, 05 Apr 2010 19:11:41 +0200")
References: <4BB652FA.2080006@opencsw.org> <x66346dpca.fsf@opencsw.org>
	<4BBA19CD.40003@opencsw.org>
Message-ID: <x6tyrpbvkr.fsf@opencsw.org>

Roger H?kansson <hson at opencsw.org> writes:

> On 2010-04-05 15:02, Peter FELECAN wrote:
>> Sebastian Kayser<skayser at opencsw.org>  writes:
>>
>>> as discussed in [1] I have finally elevated the global privileges for
>>> all maintainers in Mantis to DEVELOPER. This means, everyone should now
>>> be able to do everyday work on bugs (like moving or assigning) for _all_
>>> packages, not just the ones which one specifically owns.
>>>
>>> Questions or anything not working as expected? Please let me know.
>>>
>>> Sebastian
>>>
>>> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html
>>
>> And this answers to what requirement(s)?
>
> First of all, we have a ton of packages either orphaned or "owned" by
> absent/retired/... maintainers and if someone else starts to work on
> fixing a bug, he can't communicate with the bug reporter as its
> intended (set the status to feedback) until he has released a new
> package and becomes maintainer for the package.
>
> Also, another problem which also relates to orphaned packages is this:
> Say that you want to fix a problem in package A (which you are
> maintainer for) which depends on B which depends on C which depends on
> D. And you know that the problem is solved by upgrading/turning on a
> config-option in D so that C can autoconfig itself differently so B
> behaves diffrently which fixes the problem in A.
> Mantis have a good feature where you can daisy-chain bugs so you can
> see which bug needs to be fixed first and when its fixed the next
> maintainer can move on and so on.
> Without developer access the only way for the maintainer of A to
> achieve this is to report a bug on each package, mail the maintainers
> and ask them to manually chain them, and in case of orphaned packages,
> ask the admins to do it, even though the maintainer of A could do this
> all by him self if he had the correct permissions.
> (Which you can do now)

Thank you for this very satisfactory explanation.

>> Strangely, the assignment was not a feature available for a "developer"
>> in the messages that you refer but now it changes?
>
> Well, thats my fault, I remembered wrong what privileges a "developer"
> and a "manager" has, its been a while since I ran Mantis...

Alright, I wasn't aware about the ability to assign in that way. I'm not
very comfortable but can live with. Thank you again.
-- 
Peter

From dam at opencsw.org  Mon Apr  5 20:52:00 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 5 Apr 2010 20:52:00 +0200
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
References: <4BB3247C.8040104@clamav.net> <x6fx3ghe44.fsf@acm.org>
	<4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<4BB35DEC.4020805@opencsw.org>
	<C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
	<o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
Message-ID: <129795FD-8094-419A-A48F-D64F0FE9383B@opencsw.org>

Hi Phil,

Am 01.04.2010 um 20:30 schrieb Philip Brown:
> On Wed, Mar 31, 2010 at 7:46 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>> +1 from me. But it breaks the long-hated NFS-for-all.
> 
> Okay, we know - you dont like this method.
> That being said, I would request that we, as a group, and you
> particularly as a member of our board, refrain from making further
> remarks of this type?
> 
> Okay, you dont like it. But there are still quite a few places that
> share out software via NFS.
> Or other methods that functional for packaging purposes, effectively
> similar to it.
> (eg: rsync)
> 
> To talk like this, is to insult our customers' choices. Not a good
> thing at the best of times, but when the choice in this particular
> case is a perfectly valid one, especially makes us look bad.

Then I would like to request two things:

1. Make clear what we actually support and how we do that.
NFS from Solaris 9 to Solaris 10? Only from Solaris 10 to
Solaris 10? How are configuration files are handled?
RC-Scripts? SMF? etc.

2. At least one maintainer who actually drives things in terms
of NFS-sharing-compliance. I am willing to do some courtesy
work, but this goes beyond my line. If the big shops want this
feature they can provide someone who works on it.


Best regards

  -- Dago


From dam at opencsw.org  Mon Apr  5 21:06:40 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 5 Apr 2010 21:06:40 +0200
Subject: [csw-maintainers] python - illegal compiler flag ?
In-Reply-To: <h2p6af4271004020133n5a02effeoad8d09d3c5c89315@mail.gmail.com>
References: <h2p6af4271004020133n5a02effeoad8d09d3c5c89315@mail.gmail.com>
Message-ID: <8CCF2CE7-E5C8-4546-83C4-80A640EEA67E@opencsw.org>

Hi Rupert,

Am 02.04.2010 um 10:33 schrieb rupert THURNER:
> while building mercurial-1.5.1 i got the error, on both build9s, and build9x:
> 
> /opt/studio/SOS11/SUNWspro/bin/cc -G -m32 -xarch=386 -L/opt/csw/lib
> -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include
> build/temp.solaris-2.9-i86pc-2.6/mercurial/parsers.o -L/opt/csw/lib
> -lpython2.6 -o build/lib.solaris-2.9-i86pc-2.6/mercurial/parsers.so
> cc: Warning: illegal option -m32
> cc: Warning: illegal option -m32
> 
> it compiles, so the package is on testing now.

This is strange. GAR doesn't use -m32 on SOS11, I just checked ([1]). Is this
added by mercurial itself?

Best regards

  -- Dago



[1] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.conf.mk#L322

From dam at opencsw.org  Mon Apr  5 21:11:11 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 5 Apr 2010 21:11:11 +0200
Subject: [csw-maintainers] 64-bit python (was evince-2.24.2 in
	experimental)
In-Reply-To: <4BB5B91F.1010107@opencsw.org>
References: <ce97543b1003050400x153cdb36r7c98f5154905b5f1@mail.gmail.com>
	<ce97543b1003080328n740fd5c9gb281ba8ce41e22c7@mail.gmail.com>
	<ce97543b1003090004o3740fdc7i2ab86870b7dccc92@mail.gmail.com>
	<4B9614B0.7030503@cmi.univ-mrs.fr>	<ce97543b1003100045l5b0d179s8d83eba2c72896b1@mail.gmail.com>
	<ce97543b1003102345q572e1241v530d8976d7531f55@mail.gmail.com>
	<ce97543b1003102356s5a26a090iea389c91e15da163@mail.gmail.com>
	<4B989CCA.2060409@opencsw.org>	<ce97543b1003110046k12567a32ic3da53b4490716d5@mail.gmail.com>
	<4B98B139.8020001@opencsw.org>
	<ce97543b1003110107t523036afwced68e5c949e65e8@mail.gmail.com>
	<4BB5B91F.1010107@opencsw.org>
Message-ID: <715E80A5-F3EE-4EE0-8D5E-393DBFF9AC48@opencsw.org>

Hi Roger,

Am 02.04.2010 um 11:30 schrieb Roger H?kansson:
> On 2010-03-11 10:07, Maciej (Matchek) Blizinski wrote:
>> On Thu, Mar 11, 2010 at 9:00 AM, Roger H?kansson<hson at opencsw.org>  wrote:
>>> On 2010-03-11 09:46, Maciej (Matchek) Blizinski wrote:
>>>> but lcms depends on Python, which is not, and
>>>> will not, in the nearest future, be available in 64-bit.
>>> 
>>> Why not?
>> 
>> I've looked at it once.  Python headers do checks on certain 64-bit
>> related constants, which AFAIK are set by the compiler; the assertions
>> in the Python code are failing.
>> 
>> "/opt/csw/include/python2.6/pyport.h", line 680: Error: #error
>> "LONG_BIT definition appears wrong for platform (bad gcc/glibc
>> config?).".
> 
> The problem is that you need to "merge" pyconfig.h from both 32-bit and 64-bit and add some ifdefs to switch between them.
> How/if this can be done using GAR I have no idea.

There is currently no built-in in GAR to do this as I have only encountered
this (headers different between 32/64 bit) once: for curl.
The solution is to make a wrapper for the header which branches for 32/64 bit
and then pull in the renamed "real" includes like this:
  <http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/curl/trunk/files/curlbuild.h>

> /* Allow 32 and 64 bit headers to coexist */
> #if defined __amd64 || defined __x86_64 || defined __sparcv9
> #include "curlbuild-64.h"
> #else
> #include "curlbuild-32.h"
> #endif


The renaming in GAR is done during merge like this:

> EXTRA_PAX_ARGS_32 = -s ",^\.$(includedir)/curl/curlbuild.h$$,.$(includedir)/curl/curlbuild-32.h,p"
> EXTRA_PAX_ARGS_64 = -s ",^\.$(includedir)/curl/curlbuild.h$$,.$(includedir)/curl/curlbuild-64.h,p"
> EXTRA_PAX_ARGS = $(EXTRA_PAX_ARGS_$(MEMORYMODEL))

Best regards

  -- Dago



From dam at opencsw.org  Mon Apr  5 21:23:01 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 5 Apr 2010 21:23:01 +0200
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <4BB83D49.20806@opencsw.org>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
Message-ID: <205A0887-D833-4F66-BE24-3384479BF838@opencsw.org>

Hi,

Am 04.04.2010 um 09:18 schrieb Roger H?kansson:
> On 2010-04-04 08:27, Jeffery Small wrote:
>> When I do a pkgchk -l CSWxpdf, it
>> reports that files like pdffonts, pdfimages, pdfinfo, pdftoppm, pdftops,
>> and pdftotext are referenced by packages CSWpoppler and CSWxpdf.  I'm gonna'
>> take a guess here and say that there may be a conflict between these two
>> packages and that may somehow be responsible for CSWxpdf getting trashed -
>> possibly when CSWpoppler is upgraded?
> 
> Yes there is a conflict between CSWpoppler and CSWxpdf due to the fact that poppler is a fork of the xpdf source and they have kept the binary names. CSWpoppler have CSWxpdf marked as incompatible so you should not be able to install it by mistake, however CSWxpdf does not have CSWpoppler as incompatible (yet).

Maybe the binaries should be suffixed with the package like
  xpdf.xpdf
  xpdf.poppler
with alternatives for selection? Would circument the ugly "Incompatible".


Best regards

  -- Dago


From dam at opencsw.org  Mon Apr  5 21:25:27 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 5 Apr 2010 21:25:27 +0200
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <L0DsGt.KKM@cjsa.com>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
	<L0DsGt.KKM@cjsa.com>
Message-ID: <D5484821-7436-430E-ADC8-78114397405C@opencsw.org>

Hi Jeff,

Am 05.04.2010 um 04:05 schrieb Jeffery Small:
> Stuff like this makes the entire CSW tree unpredictable.  You can't have
> one package simply removing another!  And I consider xpdf to be a very
> valuable program.  It's 5 times faster than Adobe Reader.

Thank you for reporting this. I am sure we find a viable solution for
your problem soon. A more elaborated testing staga has been suggested
on the list but unfortunately hasn't been implemented yet.


Best regards

  -- Dago


[1] http://wiki.opencsw.org/releases-and-staging

From phil at opencsw.org  Mon Apr  5 21:39:51 2010
From: phil at opencsw.org (Philip Brown)
Date: Mon, 5 Apr 2010 12:39:51 -0700
Subject: [csw-maintainers] cswpkgloghooks, shell choices
Message-ID: <v2xd57eab941004051239z981e9eddgbbe2a538df729eac@mail.gmail.com>

(redirected from the pkgsubmissions list: prior subject
[csw-pkgsubmissions] newpkgs cswpkgloghooks  )



On Thu, Apr 1, 2010 at 12:02 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Thu Apr 01 14:55:57 -0400 2010:
>
>> Although really, better still would be to just program in standard sh
>
> Standard sh sucks. ?I won't use it for anything other than forking
> something useful.
>

ksh is standard (been there since almost forever), and is even on boot cdroms.
But you wont use that either, I presume.... The true reason, I'm
guessing, being that "it's not bash" :-)

From bwalton at opencsw.org  Mon Apr  5 21:46:49 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 05 Apr 2010 15:46:49 -0400
Subject: [csw-maintainers] cswpkgloghooks, shell choices
In-Reply-To: <v2xd57eab941004051239z981e9eddgbbe2a538df729eac@mail.gmail.com>
References: <v2xd57eab941004051239z981e9eddgbbe2a538df729eac@mail.gmail.com>
Message-ID: <1270496520-sup-4923@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Apr 05 15:39:51 -0400 2010:

> ksh is standard (been there since almost forever), and is even on
> boot cdroms.  But you wont use that either, I presume.... The true
> reason, I'm guessing, being that "it's not bash" :-)

You presume wrong.  If I was familiar with ksh, I'd turn to that
first.  I'm not...and I see _zero_ value in learning it in 2010.  Bash
is 'standard enough' as it's on sol8+, which for CSW purposes is all
that's required.  It lets me do things without calling out to external
tools for something simple like this, which is why I didn't turn to
xpg4/bin/sh.

If, hypothetically, bash isn't an acceptable, my next tool (when
looking for something widely available) would be perl...

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


From bwalton at opencsw.org  Mon Apr  5 21:47:46 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 05 Apr 2010 15:47:46 -0400
Subject: [csw-maintainers] cswpkgloghooks, shell choices
In-Reply-To: <v2xd57eab941004051239z981e9eddgbbe2a538df729eac@mail.gmail.com>
References: <v2xd57eab941004051239z981e9eddgbbe2a538df729eac@mail.gmail.com>
Message-ID: <1270496821-sup-4261@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Apr 05 15:39:51 -0400 2010:

> > Standard sh sucks. ?I won't use it for anything other than forking
> > something useful.

To clarify this, I'm referring to /bin/sh.  It should be actively
avoided in my opinion.

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


From rupert at opencsw.org  Mon Apr  5 22:00:21 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Mon, 5 Apr 2010 22:00:21 +0200
Subject: [csw-maintainers] python - illegal compiler flag ?
In-Reply-To: <8CCF2CE7-E5C8-4546-83C4-80A640EEA67E@opencsw.org>
References: <h2p6af4271004020133n5a02effeoad8d09d3c5c89315@mail.gmail.com> 
	<8CCF2CE7-E5C8-4546-83C4-80A640EEA67E@opencsw.org>
Message-ID: <i2t6af4271004051300o5752acbet6fb0c6364964585a@mail.gmail.com>

On Mon, Apr 5, 2010 at 21:06, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Rupert,
>
> Am 02.04.2010 um 10:33 schrieb rupert THURNER:
>> while building mercurial-1.5.1 i got the error, on both build9s, and build9x:
>>
>> /opt/studio/SOS11/SUNWspro/bin/cc -G -m32 -xarch=386 -L/opt/csw/lib
>> -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include
>> build/temp.solaris-2.9-i86pc-2.6/mercurial/parsers.o -L/opt/csw/lib
>> -lpython2.6 -o build/lib.solaris-2.9-i86pc-2.6/mercurial/parsers.so
>> cc: Warning: illegal option -m32
>> cc: Warning: illegal option -m32
>>
>> it compiles, so the package is on testing now.
>
> This is strange. GAR doesn't use -m32 on SOS11, I just checked ([1]). Is this
> added by mercurial itself?

to my knowledge setuptools compilation use the flags used to compile python.

rupert.

From dam at opencsw.org  Mon Apr  5 22:02:27 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 5 Apr 2010 22:02:27 +0200
Subject: [csw-maintainers] python - illegal compiler flag ?
In-Reply-To: <i2t6af4271004051300o5752acbet6fb0c6364964585a@mail.gmail.com>
References: <h2p6af4271004020133n5a02effeoad8d09d3c5c89315@mail.gmail.com>
	<8CCF2CE7-E5C8-4546-83C4-80A640EEA67E@opencsw.org>
	<i2t6af4271004051300o5752acbet6fb0c6364964585a@mail.gmail.com>
Message-ID: <AE503679-727B-444B-9B0A-F30735C25C64@opencsw.org>

Hi Rupert,

Am 05.04.2010 um 22:00 schrieb rupert THURNER:
> On Mon, Apr 5, 2010 at 21:06, Dagobert Michelsen <dam at opencsw.org> wrote:
>> Hi Rupert,
>> 
>> Am 02.04.2010 um 10:33 schrieb rupert THURNER:
>>> while building mercurial-1.5.1 i got the error, on both build9s, and build9x:
>>> 
>>> /opt/studio/SOS11/SUNWspro/bin/cc -G -m32 -xarch=386 -L/opt/csw/lib
>>> -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include
>>> build/temp.solaris-2.9-i86pc-2.6/mercurial/parsers.o -L/opt/csw/lib
>>> -lpython2.6 -o build/lib.solaris-2.9-i86pc-2.6/mercurial/parsers.so
>>> cc: Warning: illegal option -m32
>>> cc: Warning: illegal option -m32
>>> 
>>> it compiles, so the package is on testing now.
>> 
>> This is strange. GAR doesn't use -m32 on SOS11, I just checked ([1]). Is this
>> added by mercurial itself?
> 
> to my knowledge setuptools compilation use the flags used to compile python.

Than most certainly Python was compiled with Sun Studio 12 and you
hardwired CC to Sun Studio 11 :-)


Best regards

  -- Dago


From phil at bolthole.com  Mon Apr  5 22:03:33 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 5 Apr 2010 13:03:33 -0700
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <1270431512-sup-8336@pinkfloyd.chass.utoronto.ca>
References: <4BB3247C.8040104@clamav.net> <x6fx3ghe44.fsf@acm.org>
	<4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<4BB35DEC.4020805@opencsw.org>
	<C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
	<o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
	<1270431512-sup-8336@pinkfloyd.chass.utoronto.ca>
Message-ID: <t2rd57eab941004051303ja9b20756zf60181f1d41184f4@mail.gmail.com>

On Sun, Apr 4, 2010 at 6:45 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Thu Apr 01 14:30:24 -0400 2010:
>
>> To talk like this, is to insult our customers' choices. Not a good
>> thing at the best of times, but when the choice in this particular
>> case is a perfectly valid one, especially makes us look bad.
>
> It was _clearly_ not Dago's intent to insult anyone with his remarks.
> Anyone that would take offense at the comment is someone that's easily
> offended in general...
>

That is a very debian approach.

I would like to say that is one aspect of debian, i would like to NOT
replicate at opencsw.

From phil at bolthole.com  Mon Apr  5 22:11:22 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 5 Apr 2010 13:11:22 -0700
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <129795FD-8094-419A-A48F-D64F0FE9383B@opencsw.org>
References: <4BB3247C.8040104@clamav.net> <x6fx3ghe44.fsf@acm.org>
	<4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<4BB35DEC.4020805@opencsw.org>
	<C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
	<o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
	<129795FD-8094-419A-A48F-D64F0FE9383B@opencsw.org>
Message-ID: <i2nd57eab941004051311qe6eca1u58d47df49c9d7abd@mail.gmail.com>

On Mon, Apr 5, 2010 at 11:52 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Phil,
>

*wave*


> Then I would like to request two things:
>
> 1. Make clear what we actually support and how we do that.
> NFS from Solaris 9 to Solaris 10? Only from Solaris 10 to
> Solaris 10? How are configuration files are handled?
> RC-Scripts? SMF? etc.

A very sensible request. Thank you for taking things forward constructively :)
I agree that we should probably document this sort of thing more. And
I am willing to take this "action item" and implement it myself.

Hopefully, I will have some time tonight to do it, or wednesday worst case.


> 2. At least one maintainer who actually drives things in terms
> of NFS-sharing-compliance. I am willing to do some courtesy
> work, but this goes beyond my line. If the big shops want this
> feature they can provide someone who works on it.

It would appear that I am probably the point person on this sort  of
thing. But I welcome help from other maintainers as well. Or, even
other folks.
As Secretary, perhaps you might solicit a request for interested
parties on the users' list, Dago?
For people who currently deploy in "shared read-only /opt" in some
capacity, and are interested in making csw packages better in that
area?

You could mention that this might not actually require maintaining a
package, but be more of a tech resource, and "focus group", if you
will.

From bwalton at opencsw.org  Mon Apr  5 22:20:01 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 05 Apr 2010 16:20:01 -0400
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <t2rd57eab941004051303ja9b20756zf60181f1d41184f4@mail.gmail.com>
References: <4BB3247C.8040104@clamav.net> <x6fx3ghe44.fsf@acm.org>
	<4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<4BB35DEC.4020805@opencsw.org>
	<C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
	<o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
	<1270431512-sup-8336@pinkfloyd.chass.utoronto.ca>
	<t2rd57eab941004051303ja9b20756zf60181f1d41184f4@mail.gmail.com>
Message-ID: <1270498757-sup-9582@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Apr 05 16:03:33 -0400 2010:
> On Sun, Apr 4, 2010 at 6:45 PM, Ben Walton <bwalton at opencsw.org> wrote:
> > Excerpts from Philip Brown's message of Thu Apr 01 14:30:24 -0400 2010:
> >
> >> To talk like this, is to insult our customers' choices. Not a good
> >> thing at the best of times, but when the choice in this particular
> >> case is a perfectly valid one, especially makes us look bad.
> >
> > It was _clearly_ not Dago's intent to insult anyone with his remarks.
> > Anyone that would take offense at the comment is someone that's easily
> > offended in general...
> >
> 
> That is a very debian approach.

Ok, now I'm completely lost...Debian approach?

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


From phil at bolthole.com  Mon Apr  5 22:23:54 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 5 Apr 2010 13:23:54 -0700
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <1270498757-sup-9582@pinkfloyd.chass.utoronto.ca>
References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<4BB35DEC.4020805@opencsw.org>
	<C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
	<o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
	<1270431512-sup-8336@pinkfloyd.chass.utoronto.ca>
	<t2rd57eab941004051303ja9b20756zf60181f1d41184f4@mail.gmail.com>
	<1270498757-sup-9582@pinkfloyd.chass.utoronto.ca>
Message-ID: <v2sd57eab941004051323v27a0c4d0y90d838b43e212bb8@mail.gmail.com>

On Mon, Apr 5, 2010 at 1:20 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon Apr 05 16:03:33 -0400 2010:
>> That is a very debian approach.
>
> Ok, now I'm completely lost...Debian approach?

I was referring to,

>> > Anyone that would take offense at the comment is someone that's easily
>> > offended in general...

ie: "if someone gets offended, it's THEIR fault, not the speaker".

but anyways, I'm happy that we now have a positive direction to move
towards, so I dont have anything further to say about it.

From phil at bolthole.com  Mon Apr  5 22:31:43 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 5 Apr 2010 13:31:43 -0700
Subject: [csw-maintainers] cswpkgloghooks, shell choices
In-Reply-To: <1270496520-sup-4923@pinkfloyd.chass.utoronto.ca>
References: <v2xd57eab941004051239z981e9eddgbbe2a538df729eac@mail.gmail.com>
	<1270496520-sup-4923@pinkfloyd.chass.utoronto.ca>
Message-ID: <v2od57eab941004051331z99e4e51cs8d42570d96cbf5d4@mail.gmail.com>

On Mon, Apr 5, 2010 at 12:46 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon Apr 05 15:39:51 -0400 2010:
>
>> ksh is standard (been there since almost forever), and is even on
>> boot cdroms. ?But you wont use that either, I presume.... The true
>> reason, I'm guessing, being that "it's not bash" :-)
>
> You presume wrong. ?If I was familiar with ksh, I'd turn to that
> first.

oh, wonderful!


>?I'm not...and I see _zero_ value in learning it in 2010. ?Bash
> is 'standard enough'

except that this reinforces my original assumption :-}
but hang on a minute....

> as it's on sol8+, which for CSW purposes is all
> that's required. ?It lets me do things without calling out to external
> tools for something simple like this, which is why I didn't turn to
> xpg4/bin/sh.
>

Some points for your consideration,though:

1. /bin/ksh actually has most of the useful features of xpg4/bin/sh

2. Similarly, most built-in things in bash, are also built-in for ksh.

PS; technically, i think bash is still *optional* for sol8.
It's not in SUNWCreq
It's also "optional" in sol9. again, not in SUNWCreq.
Checking...
Nope, it's not in sol10 SUNWCreq either. So it's still in "optional"
status for sol10!

But ksh is *always* there. (It's part of SUNWcsu, even)

From phil at bolthole.com  Mon Apr  5 22:33:19 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 5 Apr 2010 13:33:19 -0700
Subject: [csw-maintainers] cswpkgloghooks, shell choices
In-Reply-To: <v2od57eab941004051331z99e4e51cs8d42570d96cbf5d4@mail.gmail.com>
References: <v2xd57eab941004051239z981e9eddgbbe2a538df729eac@mail.gmail.com>
	<1270496520-sup-4923@pinkfloyd.chass.utoronto.ca>
	<v2od57eab941004051331z99e4e51cs8d42570d96cbf5d4@mail.gmail.com>
Message-ID: <i2zd57eab941004051333wd5c05600id23baa1c5864db8b@mail.gmail.com>

PPS:


On Mon, Apr 5, 2010 at 1:31 PM, Philip Brown <phil at bolthole.com> wrote:
>
> 1. /bin/ksh actually has most of the useful features of xpg4/bin/sh
>

actually, ksh virtually IS xpg4/bin/sh... but with extras too :)

From phil at bolthole.com  Mon Apr  5 22:37:55 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 5 Apr 2010 13:37:55 -0700
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <4BB83D49.20806@opencsw.org>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
Message-ID: <v2rd57eab941004051337gc460ed50if34cfff46d52a16d@mail.gmail.com>

On Sun, Apr 4, 2010 at 12:18 AM, Roger H?kansson <hson at opencsw.org> wrote:
> On 2010-04-04 08:27, Jeffery Small wrote:
>>
>> When I do a pkgchk -l CSWxpdf, it
>> reports that files like pdffonts, pdfimages, pdfinfo, pdftoppm, pdftops,
>> and pdftotext are referenced by packages CSWpoppler and CSWxpdf. ?I'm
>> gonna'
>> take a guess here and say that there may be a conflict between these two
>> packages and that may somehow be responsible for CSWxpdf getting trashed -
>> possibly when CSWpoppler is upgraded?
>
> Yes there is a conflict between CSWpoppler and CSWxpdf due to the fact that
> poppler is a fork of the xpdf source and they have kept the binary names.
> CSWpoppler have CSWxpdf marked as incompatible so you should not be able to
> install it by mistake, however CSWxpdf does not have CSWpoppler as
> incompatible (yet).
> ________________


aaak. you should have kept the older poppler package ideosyncracies!

Roger, please repackage poppler along the old package standards.

that is to say: nothing in /opt/csw/bin
Then you can remove the xpdf conflict also.

From bwalton at opencsw.org  Tue Apr  6 01:06:32 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 05 Apr 2010 19:06:32 -0400
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <v2sd57eab941004051323v27a0c4d0y90d838b43e212bb8@mail.gmail.com>
References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net>
	<u2m625385e31003310715y8ca85af6p126b898ba0ee1be5@mail.gmail.com>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<4BB35DEC.4020805@opencsw.org>
	<C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
	<o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
	<1270431512-sup-8336@pinkfloyd.chass.utoronto.ca>
	<t2rd57eab941004051303ja9b20756zf60181f1d41184f4@mail.gmail.com>
	<1270498757-sup-9582@pinkfloyd.chass.utoronto.ca>
	<v2sd57eab941004051323v27a0c4d0y90d838b43e212bb8@mail.gmail.com>
Message-ID: <1270508554-sup-357@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Apr 05 16:23:54 -0400 2010:

> >> > Anyone that would take offense at the comment is someone that's easily
> >> > offended in general...
> 
> ie: "if someone gets offended, it's THEIR fault, not the speaker".

I've seen this theme pop up a few times lately (in completely
unrelated contexts) and I'll say it again: Taking offense at something
is stupid.  It implies that the speaker should put their own thoughts
at a lesser standing than the 'hearer.'  The notion of offense is that
of taking a non-personal statement and being insulted by it.  So, if
you take offense at something, it's inherently your 'fault' for doing
so.  It restricts the ability of someone to properly speak their mind
which leads us to the insane levels of political correctness we have
today.

Had Dago specified someone/something personal then yes, someone could
rightly take _insult_ at such a statement.  That is clearly not the
case here.

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


From phil at bolthole.com  Tue Apr  6 01:47:57 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 5 Apr 2010 16:47:57 -0700
Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 -
	Intel
In-Reply-To: <1270508554-sup-357@pinkfloyd.chass.utoronto.ca>
References: <4BB3247C.8040104@clamav.net>
	<CE6DCE2F-5E80-4928-9549-720E9ADEF749@opencsw.org>
	<4BB35DEC.4020805@opencsw.org>
	<C6C6F692-8A1F-4B3C-947E-3760066B0933@opencsw.org>
	<o2od57eab941004011130j85c556f4o7c564c230fb63dd@mail.gmail.com>
	<1270431512-sup-8336@pinkfloyd.chass.utoronto.ca>
	<t2rd57eab941004051303ja9b20756zf60181f1d41184f4@mail.gmail.com>
	<1270498757-sup-9582@pinkfloyd.chass.utoronto.ca>
	<v2sd57eab941004051323v27a0c4d0y90d838b43e212bb8@mail.gmail.com>
	<1270508554-sup-357@pinkfloyd.chass.utoronto.ca>
Message-ID: <x2pd57eab941004051647i7cbbf65fx242cd05b36ac75ec@mail.gmail.com>

On Mon, Apr 5, 2010 at 4:06 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon Apr 05 16:23:54 -0400 2010:
>
>> >> > Anyone that would take offense at the comment is someone that's easily
>> >> > offended in general...
>>
>> ie: "if someone gets offended, it's THEIR fault, not the speaker".
>....
>
> Had Dago specified someone/something personal then yes, someone could
> rightly take _insult_ at such a statement. ?That is clearly not the
> case here.
>

perhaps I wasnt being clear in my choice of words earlier.

I dont think that Dago's remark was directed at any one person in
general. I dont believe it was a "personal attack" on anyone.
That being said, there's more than one way to cause insult.
Some 3rd party examples, that may or may not resonate with you:

 When Sun decided, many years ago, to drop solaris x86, I felt
insulted, as a customer.

  When Oracle decided recently, to limit licensing of solaris to no
longer be 100%, all the time, and require a support contract for ALL
deployments,  I felt insulted, as a customer.

A remark, or action, does not have to be directed at a specific
person, to cause "insult" to a customer.

To state it in a more directly relevant fashion:

When a business, or organization, says, "the way that you choose to
run your IT department, is stupid/dumb/obsolete/'hated' "...  That Is
Insulting.

And that was what happened here.

From bwalton at opencsw.org  Tue Apr  6 01:50:07 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 05 Apr 2010 19:50:07 -0400
Subject: [csw-maintainers] cswpkgloghooks, shell choices
In-Reply-To: <i2zd57eab941004051333wd5c05600id23baa1c5864db8b@mail.gmail.com>
References: <v2xd57eab941004051239z981e9eddgbbe2a538df729eac@mail.gmail.com>
	<1270496520-sup-4923@pinkfloyd.chass.utoronto.ca>
	<v2od57eab941004051331z99e4e51cs8d42570d96cbf5d4@mail.gmail.com>
	<i2zd57eab941004051333wd5c05600id23baa1c5864db8b@mail.gmail.com>
Message-ID: <1270511253-sup-8840@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Apr 05 16:33:19 -0400 2010:

> actually, ksh virtually IS xpg4/bin/sh... but with extras too :)

Yes, but as stated earlier, I already know the extras in bash and am
not interested in learning the idiosyncrasies of yet another shell.
(Read: I'm not interested in doing everything in your view of 'the
solaris way.')  The only change I'd make from bash is to perl, for the
originally stated reason.  Learning ksh in 2010 is of _zero_ value to
_me_.

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


From james at opencsw.org  Tue Apr  6 10:58:12 2010
From: james at opencsw.org (James Lee)
Date: Tue, 06 Apr 2010 08:58:12 GMT
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <D5484821-7436-430E-ADC8-78114397405C@opencsw.org>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
	<L0DsGt.KKM@cjsa.com>
	<D5484821-7436-430E-ADC8-78114397405C@opencsw.org>
Message-ID: <20100406.8581200.3876240886@gyor.oxdrove.co.uk>

On 05/04/10, 20:25:27, Dagobert Michelsen <dam at opencsw.org> wrote regarding
Re: [csw-maintainers] Upgrade problems??:

> Am 05.04.2010 um 04:05 schrieb Jeffery Small:
> > Stuff like this makes the entire CSW tree unpredictable.  You can't have
> > one package simply removing another!  And I consider xpdf to be a very
> > valuable program.  It's 5 times faster than Adobe Reader.

> Thank you for reporting this. I am sure we find a viable solution for
> your problem soon. A more elaborated testing staga has been suggested
> on the list but unfortunately hasn't been implemented yet.

http://www.opencsw.org/bugtrack/view.php?id=4339


and I'll add I feel insulted.



James.

From dam at opencsw.org  Tue Apr  6 11:39:43 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 6 Apr 2010 11:39:43 +0200
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <20100406.8581200.3876240886@gyor.oxdrove.co.uk>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
	<L0DsGt.KKM@cjsa.com>
	<D5484821-7436-430E-ADC8-78114397405C@opencsw.org>
	<20100406.8581200.3876240886@gyor.oxdrove.co.uk>
Message-ID: <2D34D1F7-A07E-4A18-97A5-8E25801956A2@opencsw.org>

Hi James,

Am 06.04.2010 um 10:58 schrieb James Lee:
> On 05/04/10, 20:25:27, Dagobert Michelsen <dam at opencsw.org> wrote  
> regarding
> Re: [csw-maintainers] Upgrade problems??:
>
>> Am 05.04.2010 um 04:05 schrieb Jeffery Small:
>>> Stuff like this makes the entire CSW tree unpredictable.  You  
>>> can't have
>>> one package simply removing another!  And I consider xpdf to be a  
>>> very
>>> valuable program.  It's 5 times faster than Adobe Reader.
>
>> Thank you for reporting this. I am sure we find a viable solution for
>> your problem soon. A more elaborated testing staga has been suggested
>> on the list but unfortunately hasn't been implemented yet.
>
> http://www.opencsw.org/bugtrack/view.php?id=4339
>
> and I'll add I feel insulted.

Why is that? You found the problem, but as it looks the "fix" from
Roger was not appropriate. As we don't have release stages between
current and stable the updated poppler hit users from current/
instead of something before that. IMHO it would be good to have
a release stage before current which gets promoted to current
if there are no more known issues.


Best regards

   -- Dago

From dam at opencsw.org  Tue Apr  6 16:22:58 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 6 Apr 2010 16:22:58 +0200
Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL
Message-ID: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org>

Hi,

I am experimenting in doing specific compiles for SUNW X11 and
CSW X11 to provide accelerated 3D with SUNW X11 while allowing
up-to-date packages with OpenCSW X11. Some notes:

(1) Package names and contents
I suggest making different sets of packages,
   CSW<pkg>    bound against SUNW X11
   CSWx11<pkg> bound against OpenCSW X11
where <pkg> conforms to regular naming standards, like *rt, etc.
The files in CSWx11<pkg> are in /opt/csw/X11/* while the files for
CSW<pkg> are in regular /opt/csw/(lib|...) locations. This way
existing binaries without OpenCSW X11 can continue to work.
Only CSWx11<pkg> depends on CSWx11smi, CSWx11libx11, etc.

(2) OpenGL
Solaris 9 doesn't have an OpenGL binding by default. There is one at
   <http://www.sun.com/software/graphics/opengl/download.xml>
for Solaris 9 Sparc, but not x86. Solaris 10 has a bundled gl.h, but
in GL/gl.h where e.h. giflib checks for gl/gl.h. Are these different
libs or is there a link or something missing? And when I compile
on Solaris 9 SUNWglrt is an optional package which I can not rely
on. How should I proceed here? Compile without OpenGL on Solaris 9
and only depend on Solaris 10 builtin OpenGL?


The first set of packages (giflib) compiled without OpenGL on
Solaris 9 only, separate CSW X11 and SUNW X11 version is
available at
   <http://mirror.opencsw.org/experimental.html#x11>
for inspection.


Best regards

   -- Dago

From phil at bolthole.com  Tue Apr  6 21:08:17 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 6 Apr 2010 12:08:17 -0700
Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL
In-Reply-To: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org>
References: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org>
Message-ID: <z2qd57eab941004061208x4d82669u100fc120d16e92e3@mail.gmail.com>

On Tue, Apr 6, 2010 at 7:22 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>
> (2) OpenGL
> Solaris 9 doesn't have an OpenGL binding by default.

I dont even understand that statement.
What do you mean, "binding" ?

> And when I compile
> on Solaris 9 SUNWglrt is an optional package which I can not rely
> on. How should I proceed here? Compile without OpenGL on Solaris 9
> and only depend on Solaris 10 builtin OpenGL?


compile against OUR OpenGL providing package, which Makes Things Work,
automagically.

(mesalibs, if I recall correct)

it provides libGL. it also provides the headers.

Then if sun opengl is present, the program will use that at runtime.
Its that aux filter thing again.

From phil at bolthole.com  Tue Apr  6 21:44:31 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 6 Apr 2010 12:44:31 -0700
Subject: [csw-maintainers] reminder about "incompatible packages"
Message-ID: <w2ld57eab941004061244g9fd67332v907eaf90ba9b3d39@mail.gmail.com>

Hi folks,

a reminder about marking packages as "incompatible":

It is NOT okay to ship the same executables (in the exact same path)
as another package, and just mark your package as "incompatible" with
the other one.

All packages sitting in "current", must peacably co-exist with each other.

The "incompatible" flag, is only to be used when a NEW package, is
designed to override an OLD package, that *no longer exists*, in our
current repository.

From phil at bolthole.com  Wed Apr  7 04:54:34 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 6 Apr 2010 19:54:34 -0700
Subject: [csw-maintainers] use of /opt/csw/etc
Message-ID: <m2zd57eab941004061954l162c9309o1383a622ef45b541@mail.gmail.com>

btw, I hope to find time to write up some stuff on NFS tomorrow. but
while I think of it, here is an example of appropriate
 "global configuration" in /opt/csw/etc
that I just found in our packages:

/opt/csw/etc/fontconfig/fonts.conf

Without a "fonts.conf" file, fontconfig basically Does Not Work. So
you must supply one, across all machines you deploy /opt/csw to.
And, it is very unlikely (to say the least), that you would ever need
to have machine-local tweaks to this file.
It is basically configured at pkgadd time, and never messed with.

Although ideally, a package would allow for sysadmin customization,
and create the global one from a presumed template.
which our fontconfig package unfortunately does not :-}

From skayser at opencsw.org  Wed Apr  7 20:11:13 2010
From: skayser at opencsw.org (Sebastian Kayser)
Date: Wed, 7 Apr 2010 20:11:13 +0200
Subject: [csw-maintainers] Mantis privileges elevated to allow
	for	easier cross-package collaboration
In-Reply-To: <x6y6h1bvqg.fsf@opencsw.org>
References: <4BB652FA.2080006@opencsw.org> <x66346dpca.fsf@opencsw.org>
	<4BBA18A4.8010809@opencsw.org> <x6y6h1bvqg.fsf@opencsw.org>
Message-ID: <20100407181113.GS27943@sebastiankayser.de>

* Peter FELECAN <pfelecan at opencsw.org> wrote:
> Sebastian Kayser <skayser at opencsw.org> writes:
> 
> > Peter FELECAN wrote on 05.04.2010 15:02:
> >> Sebastian Kayser <skayser at opencsw.org> writes:
> >> 
> >>> as discussed in [1] I have finally elevated the global privileges for
> >>> all maintainers in Mantis to DEVELOPER. This means, everyone should now
> >>> be able to do everyday work on bugs (like moving or assigning) for _all_
> >>> packages, not just the ones which one specifically owns.
> >>>
> >>> Questions or anything not working as expected? Please let me know.
> >>>
> >>> Sebastian
> >>>
> >>> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html
> >> 
> >> And this answers to what requirement(s)?
> >
> > Is this a sincere question (not quite sure, your mails seemed to have a
> > touch of irony/sarcasm lately)?
> 
> What make you doubt my sincerity? Of course, there were irony about the
> oldish releases of our beloved operating system but other than that...

Nothing in particular. The requirement seemed obvious to me after a
couple of groans from those dealing quite frequently with bugs, thus I
wanted to avoid any ambiguity. Sorry in case it came across harsher than
it should have. Thanks Roger for the comprehensive explanation.

Sebastian

From maciej at opencsw.org  Thu Apr  8 18:05:02 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 8 Apr 2010 16:05:02 +0000
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
Message-ID: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>

File conflicts appear to be a frequent problem.  There has recently
been a collision between two packages providing ev.h header.  It also
seems like Python 3.1 tries to provide /opt/csw/lib/python/os.py -- a
file which is already provided by Python 2.6.  I'm thinking of
implementing a check catching file collisions.  Directories would be
excluded from the check.  What do you think about such check?

Maciej

From bwalton at opencsw.org  Thu Apr  8 18:20:20 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 08 Apr 2010 12:20:20 -0400
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>
Message-ID: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Thu Apr 08 12:05:02 -0400 2010:

> file which is already provided by Python 2.6.  I'm thinking of
> implementing a check catching file collisions.  Directories would be
> excluded from the check.  What do you think about such check?

I think it's a great idea.  As long as it's not too heavy, and I don't
see why it would be, it should be a nice addition.

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


From phil at bolthole.com  Thu Apr  8 19:22:12 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 8 Apr 2010 10:22:12 -0700
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>
Message-ID: <h2zd57eab941004081022od2167d97v33f65b7b78655358@mail.gmail.com>

On Thu, Apr 8, 2010 at 9:05 AM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> File conflicts appear to be a frequent problem. ?There has recently
> been a collision between two packages providing ev.h header. ?It also
> seems like Python 3.1 tries to provide /opt/csw/lib/python/os.py -- a
> file which is already provided by Python 2.6. ?I'm thinking of
> implementing a check catching file collisions. ?Directories would be
> excluded from the check. ?What do you think about such check?
>

it's a good point that we "need something".

I dont see how you could possibly implement something on the GAR side though.

The good news is... I'm now doing it where it belongs. in our package database.

(or at least trying to now. there's a certain amount of cleanup I have
to do first. Like eliminating all the "directory" entries, leaving
just the "file" entries :-/ )

From phil at bolthole.com  Thu Apr  8 22:07:05 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 8 Apr 2010 13:07:05 -0700
Subject: [csw-maintainers] sparc assembly, gcc vs cc
Message-ID: <s2od57eab941004081307m83893411g804efd7294339171@mail.gmail.com>

Sooo.. I found a problem with "libffi".
 It contains the following evil, buried in the middle of a function call:

  /* Flush the Icache.  FIXME: alignment isn't certain, assume 8 bytes */

  asm volatile ("iflush %0" : : "r" (closure) : "memory");
  asm volatile ("iflush %0" : : "r" (((char *) closure) + 8) : "memory");


Does anyone have any idea how to convert this mess into something that
will be Sun CC compatible?

From phil at bolthole.com  Thu Apr  8 23:44:01 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 8 Apr 2010 14:44:01 -0700
Subject: [csw-maintainers] sparc assembly, gcc vs cc
In-Reply-To: <s2od57eab941004081307m83893411g804efd7294339171@mail.gmail.com>
References: <s2od57eab941004081307m83893411g804efd7294339171@mail.gmail.com>
Message-ID: <s2yd57eab941004081444na93c316cl28a4361d3206028b@mail.gmail.com>

On Thu, Apr 8, 2010 at 1:07 PM, Philip Brown <phil at bolthole.com> wrote:
> Sooo.. I found a problem with "libffi".
> ?It contains the following evil, buried in the middle of a function call:
>
> ?/* Flush the Icache. ?FIXME: alignment isn't certain, assume 8 bytes */
>
> ?asm volatile ("iflush %0" : : "r" (closure) : "memory");
> ?asm volatile ("iflush %0" : : "r" (((char *) closure) + 8) : "memory");
>
>
> Does anyone have any idea how to convert this mess into something that
> will be Sun CC compatible?
>


found the answer mesself.


turns out, sun cc (12 or better) actually does support this sort of
thing.. but ONLY if you turn optimization on.   Even -xO1 will do.

From phil at bolthole.com  Fri Apr  9 01:50:46 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 8 Apr 2010 16:50:46 -0700
Subject: [csw-maintainers] poppler back-revved to stable version
Message-ID: <r2od57eab941004081650l70175918zca38c3ad25dd2571@mail.gmail.com>

FYI: I have backrevved poppler to stable version, because of inconsistencies.

I now hope to continue to move forward with pending submitted pakages.

From phil at bolthole.com  Fri Apr  9 21:38:52 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 9 Apr 2010 12:38:52 -0700
Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared
	/opt/csw
In-Reply-To: <1269452532-sup-9950@pinkfloyd.chass.utoronto.ca>
References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org>
	<F08CA052-F323-4B7E-A0D9-ABFA586823DA@opencsw.org>
	<d57eab941003230856kda3c7f3w60ebca15a0fac2a6@mail.gmail.com>
	<1269360409-sup-6150@pinkfloyd.chass.utoronto.ca>
	<d57eab941003230933x5b752771wb78a0098374c113c@mail.gmail.com>
	<1269367768-sup-3364@pinkfloyd.chass.utoronto.ca>
	<d57eab941003231259p3d35d400i8f1beb9fdcae5779@mail.gmail.com>
	<1269438807-sup-5650@pinkfloyd.chass.utoronto.ca>
	<d57eab941003241038w16ee08bfpeeebadb5224b7261@mail.gmail.com>
	<1269452532-sup-9950@pinkfloyd.chass.utoronto.ca>
Message-ID: <m2td57eab941004091238m587c8385u9fb5acd972fffa48@mail.gmail.com>

Going back a waaaaayyys...


On Wed, Mar 24, 2010 at 10:44 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Wed Mar 24 13:38:04 -0400 2010:
>
>> i'm not surprised. which is why I reiterate my suggestion that we
>> should merely duplicate the user-level interface (and only the bits
>> we actually care about), and thus avoid extra baggage.
>
> But why reinvent the wheel? ?The wheel is already round and mostly
> works.


Because "fully works" is better than "mostly works"

>?With some tweaks, that as you say, should be acceptable
> upstream since they wouldn't harm the original environment, it'd be
> perfectly round for us too.

Thanks to Dago's writeups on the wiki spaces, I now have a better
understanding of how "alternatives" works.
And I now also understand Dagobert's reticence on this issue... sadly,
I dont think that this would be fixable in the redhat implementation
without majorly reengineering the way it currently works.

> Anyway. ?Since I'm not going to do the work in either scenario, I'll
> be quiet now.

Well, I am happy to say that this week, I found both my old spirit of
development, and time to indulge it, for a while!

I have now written a mostly complete, from scratch implementation of
"alternatives"
(in ksh of course:)

It currently stands at 230 lines. 52 of those are comments.
"Simpler is Better".

I anticipate "version 1.0" to be somewhere below 300 lines.

Readable, functional, and fully compatible with ALL our needs, rather
than only "mostly".

If I dont produce a test version for public consumption by tuesday,
someone please give me a nudge :)

From hson at opencsw.org  Fri Apr  9 21:59:13 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Fri, 09 Apr 2010 21:59:13 +0200
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <L0DsGt.KKM@cjsa.com>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
	<L0DsGt.KKM@cjsa.com>
Message-ID: <4BBF8711.3080901@opencsw.org>

On 2010-04-05 04:05, Jeffery Small wrote:
>
> CSWpoppler is a rendering library while CSWxpdf is a PDF viewer.
>
> CSWpoppler is required for evince, gimp and claws_pdfviewer,

And evince and claws_pdfviewer is also PDF viewers, whats your point?

Since poppler is a fork of the xpdf code without building the actual 
viewer its not surprising that there are conflicts. Which is why I made 
CSWpoppler have CSWxpdf as a incompatible package, then you'll get to 
choose which you want.



From hson at opencsw.org  Fri Apr  9 22:03:03 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Fri, 09 Apr 2010 22:03:03 +0200
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs xpdf, xpdf_utils
In-Reply-To: <s2td57eab941004051511m571f38a6v7e7dbd47635ef5cc@mail.gmail.com>
References: <201004051421.o35ELHXH020806@login.bo.opencsw.org>
	<s2td57eab941004051511m571f38a6v7e7dbd47635ef5cc@mail.gmail.com>
Message-ID: <4BBF87F7.7080809@opencsw.org>

On 2010-04-06 00:11, Philip Brown wrote:
> On Mon, Apr 5, 2010 at 7:21 AM, Benjamin von Mossner<benny at opencsw.org>  wrote:
>> Hi Phil,
>>
>> due to the conflict between CSWpoppler and CSWxpdf (#0004390)
>> xpdf is now split into two separate packages.
>>
>
> well hold off there...
> this doesnt properly resolve it.
> poppler is the one abusing the namespace. poppler is the one that
> needs to split.
> particularly since it was previously split anyways.

This most surely is the proper way to solve it.
As I've stated before, poppler is a fork of the xpdf code, so why should 
we decide which is the proper "pdftotext".
If you take a look at other dists, some have both xpdf, xpdf_utils and 
poppler(_utils) where poppler(_utils) and xpdf_utils are providing the 
same things, i.e are incompatible and the users get to choose which to 
install.


From hson at opencsw.org  Fri Apr  9 22:13:00 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Fri, 09 Apr 2010 22:13:00 +0200
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <20100406.8581200.3876240886@gyor.oxdrove.co.uk>
References: <L0C9x8.D0w@cjsa.com>
	<4BB83D49.20806@opencsw.org>	<L0DsGt.KKM@cjsa.com>	<D5484821-7436-430E-ADC8-78114397405C@opencsw.org>
	<20100406.8581200.3876240886@gyor.oxdrove.co.uk>
Message-ID: <4BBF8A4C.1000903@opencsw.org>

On 2010-04-06 10:58, James Lee wrote:
>
> http://www.opencsw.org/bugtrack/view.php?id=4339
>
>
> and I'll add I feel insulted.
>

Insulted by what?

From phil at bolthole.com  Fri Apr  9 22:23:26 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 9 Apr 2010 13:23:26 -0700
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <4BBF8711.3080901@opencsw.org>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
	<L0DsGt.KKM@cjsa.com> <4BBF8711.3080901@opencsw.org>
Message-ID: <s2yd57eab941004091323va0a647c9x4d33d5e0951788e6@mail.gmail.com>

On Fri, Apr 9, 2010 at 12:59 PM, Roger H?kansson <hson at opencsw.org> wrote:
> On 2010-04-05 04:05, Jeffery Small wrote:
>>
>> CSWpoppler is a rendering library while CSWxpdf is a PDF viewer.
>>
>> CSWpoppler is required for evince, gimp and claws_pdfviewer,
>
> And evince and claws_pdfviewer is also PDF viewers, whats your point?
>

The missing piece of the puzzle here, is that this pulls up a bit of
legacy naming problem.
evince, etc. have depended on "CSWpoppler" for a long time now.

The problem is that the actual contents of the package, would more
accurately be described as "libpoppler".

One way of getting us closer to sanity, would be to take the following steps.

1. Create new "libpoppler" packages, and submit them as official
packages. (I unfortunately had to wipe the old ones), for conflicts of
some sort.

2. Create an empty CSWpoppler and submit that for now also.

This would have the benefit of getting newer versions of the poppler
libs into our existing evince packages, and potentialy allowing newer
ones to be built, too


3. recompile evince, and the handful of other things currently
depending on "CSWpoppler", to properly depend on CSWlibpoppler

From phil at bolthole.com  Fri Apr  9 22:25:33 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 9 Apr 2010 13:25:33 -0700
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <4BBF8711.3080901@opencsw.org>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
	<L0DsGt.KKM@cjsa.com> <4BBF8711.3080901@opencsw.org>
Message-ID: <g2ld57eab941004091325i7f722717s943f966596d057fb@mail.gmail.com>

PS:


On Fri, Apr 9, 2010 at 12:59 PM, Roger H?kansson <hson at opencsw.org> wrote:
> .... Which is why I made CSWpoppler
> have CSWxpdf as a incompatible package, then you'll get to choose which you
> want.


the proper way to do this, is to rework both the xpdf package, and
poppler, to use CSWalternatives.
NOT, to mark packages as "incompatible" with other current packages.

Please note: maintainers of xpdf and poppler will have to work
together, to agree which should be the "default" xpdf, if both
packages are installed.

From hson at opencsw.org  Fri Apr  9 22:44:37 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Fri, 09 Apr 2010 22:44:37 +0200
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <g2ld57eab941004091325i7f722717s943f966596d057fb@mail.gmail.com>
References: <L0C9x8.D0w@cjsa.com>
	<4BB83D49.20806@opencsw.org>	<L0DsGt.KKM@cjsa.com>
	<4BBF8711.3080901@opencsw.org>
	<g2ld57eab941004091325i7f722717s943f966596d057fb@mail.gmail.com>
Message-ID: <4BBF91B5.40906@opencsw.org>

On 2010-04-09 22:25, Philip Brown wrote:
> the proper way to do this, is to rework both the xpdf package, and
> poppler, to use CSWalternatives.
> NOT, to mark packages as "incompatible" with other current packages.
>
> Please note: maintainers of xpdf and poppler will have to work
> together, to agree which should be the "default" xpdf, if both
> packages are installed.

Regarding xpdf, there is no collision, its the utilities (pdftotext...) 
that collide, which was why I suggested to Benny that he also split them 
out to a separate package and we make them (poppler and xpdf_utils 
incompatible).


From phil at bolthole.com  Fri Apr  9 22:48:32 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 9 Apr 2010 13:48:32 -0700
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <4BBF91B5.40906@opencsw.org>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
	<L0DsGt.KKM@cjsa.com> <4BBF8711.3080901@opencsw.org>
	<g2ld57eab941004091325i7f722717s943f966596d057fb@mail.gmail.com>
	<4BBF91B5.40906@opencsw.org>
Message-ID: <s2vd57eab941004091348z4d54506ap4f59c61fc665e3b0@mail.gmail.com>

On Fri, Apr 9, 2010 at 1:44 PM, Roger H?kansson <hson at opencsw.org> wrote:
>
> Regarding xpdf, there is no collision, its the utilities (pdftotext...) that
> collide, which was why I suggested to Benny that he also split them out to a
> separate package and we make them (poppler and xpdf_utils incompatible).
>

split to separate package: okay

make incompatible: not okay.

From hson at opencsw.org  Fri Apr  9 22:55:51 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Fri, 09 Apr 2010 22:55:51 +0200
Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL
In-Reply-To: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org>
References: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org>
Message-ID: <4BBF9457.4080508@opencsw.org>

On 2010-04-06 16:22, Dagobert Michelsen wrote:
> Hi,
>
> I am experimenting in doing specific compiles for SUNW X11 and
> CSW X11 to provide accelerated 3D with SUNW X11 while allowing
> up-to-date packages with OpenCSW X11. Some notes:
>
> (1) Package names and contents
> I suggest making different sets of packages,
> CSW<pkg> bound against SUNW X11
> CSWx11<pkg> bound against OpenCSW X11
> where <pkg> conforms to regular naming standards, like *rt, etc.
> The files in CSWx11<pkg> are in /opt/csw/X11/* while the files for
> CSW<pkg> are in regular /opt/csw/(lib|...) locations. This way
> existing binaries without OpenCSW X11 can continue to work.
> Only CSWx11<pkg> depends on CSWx11smi, CSWx11libx11, etc.
>

Wait a minute, you're proposing that we start releasing two versions of 
the same package for a ton of packages?
And the number will also increase a lot in the near future. I've been 
working on updating some gnome-apps and I think I have more than 20 new 
packages which the gnome-guys have added as build dependencies for gnome 
packages which we need to update (in order to release updated versions 
of applications).

Don't you think this will become a nightmare where in the end many 
packages with libraries need to be built in two versions just because 
some end-application need OpenCSW X11?
Lets say gimp were to need OpenCSW X11, the imagemagick would need to be 
built in two versions, graphviz, ghostscript... all the way through the 
dependency chain.
If you take a look at the list of packages on the "project X11" page, 
its not a small list and then you need to combine it with the list of 
packages that already have been rebuilt using OpenCSW X11.

I'm not familiar with the initial problem (which called for the OpenCSW 
X11), but I think this could get us digging ourselves deeper into a hole 
instead of getting us out of it.
I'm not saying that we should do it in either way, just that maybe we 
should think about it some more before hasting into a solution that 
might bite back at us later on.

From phil at bolthole.com  Fri Apr  9 23:13:00 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 9 Apr 2010 14:13:00 -0700
Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL
In-Reply-To: <4BBF9457.4080508@opencsw.org>
References: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org>
	<4BBF9457.4080508@opencsw.org>
Message-ID: <s2td57eab941004091413ye5dde8cfxef22d0d5efdb9080@mail.gmail.com>

On Fri, Apr 9, 2010 at 1:55 PM, Roger H?kansson <hson at opencsw.org> wrote:
>
> I'm not familiar with the initial problem (which called for the OpenCSW
> X11), but I think this could get us digging ourselves deeper into a hole
> instead of getting us out of it.
> I'm not saying that we should do it in either way, just that maybe we should
> think about it some more before hasting into a solution that might bite back
> at us later on.
>

agreed. Roger, please save yourself some potentially wasted effort,
and hold off on doing any compiles of gtk-related things until we
resolve this issue.

From hson at opencsw.org  Fri Apr  9 23:22:29 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Fri, 09 Apr 2010 23:22:29 +0200
Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL
In-Reply-To: <s2td57eab941004091413ye5dde8cfxef22d0d5efdb9080@mail.gmail.com>
References: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org>	<4BBF9457.4080508@opencsw.org>
	<s2td57eab941004091413ye5dde8cfxef22d0d5efdb9080@mail.gmail.com>
Message-ID: <4BBF9A95.3030208@opencsw.org>

On 2010-04-09 23:13, Philip Brown wrote:
> On Fri, Apr 9, 2010 at 1:55 PM, Roger H?kansson<hson at opencsw.org>  wrote:
>>
>> I'm not familiar with the initial problem (which called for the OpenCSW
>> X11), but I think this could get us digging ourselves deeper into a hole
>> instead of getting us out of it.
>> I'm not saying that we should do it in either way, just that maybe we should
>> think about it some more before hasting into a solution that might bite back
>> at us later on.
>>
>
> agreed. Roger, please save yourself some potentially wasted effort,
> and hold off on doing any compiles of gtk-related things until we
> resolve this issue.

Well, I'm not near releasing anything of it soon so I'll work on as 
usual on getting the dependency chains uptodate/garified which isn't 
wasted work.

From dam at opencsw.org  Sat Apr 10 09:18:01 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 10 Apr 2010 09:18:01 +0200
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <4BBF91B5.40906@opencsw.org>
References: <L0C9x8.D0w@cjsa.com>
	<4BB83D49.20806@opencsw.org>	<L0DsGt.KKM@cjsa.com>
	<4BBF8711.3080901@opencsw.org>
	<g2ld57eab941004091325i7f722717s943f966596d057fb@mail.gmail.com>
	<4BBF91B5.40906@opencsw.org>
Message-ID: <BC87A2EF-5180-41AB-9BB6-927F3214D87F@opencsw.org>

Hi Roger,

Am 09.04.2010 um 22:44 schrieb Roger H?kansson:
> On 2010-04-09 22:25, Philip Brown wrote:
>> the proper way to do this, is to rework both the xpdf package, and
>> poppler, to use CSWalternatives.
>> NOT, to mark packages as "incompatible" with other current packages.
>>
>> Please note: maintainers of xpdf and poppler will have to work
>> together, to agree which should be the "default" xpdf, if both
>> packages are installed.
>
> Regarding xpdf, there is no collision, its the utilities  
> (pdftotext...) that collide, which was why I suggested to Benny that  
> he also split them out to a separate package and we make them  
> (poppler and xpdf_utils incompatible).

It would really be the best to use alternatives to select which set
of tools would be selected. That way both packages can be installed,
no breakage, and if one or the other has some minor advantage in one
or the other environment the user can easily select the tools of
choice. It is pretty simple in GAR:
   http://sourceforge.net/apps/trac/gar/wiki/Alternatives

Benny, Roger: Just let me know if I can be of any assistance in this
issue.


Best regards

   -- Dago

From dam at opencsw.org  Sat Apr 10 09:29:21 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 10 Apr 2010 09:29:21 +0200
Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL
In-Reply-To: <4BBF9457.4080508@opencsw.org>
References: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org>
	<4BBF9457.4080508@opencsw.org>
Message-ID: <6EDEC51E-7163-4AD1-B03D-AAB40BE0504E@opencsw.org>

Hi Roger,

Am 09.04.2010 um 22:55 schrieb Roger H?kansson:
> Wait a minute, you're proposing that we start releasing two versions  
> of the same package for a ton of packages?

The main issue that we can either have a current X11 or OpenGL  
acceleration.
Every X11 thing we build must decide which way it goes (or both when  
packaged
up twice). As I don't use much 3D anyway I honestly don't know which  
libs
would be needed for apps that benefit from it.

There is the additional problem that James encountered apps breaking  
after
we changed libs in /opt/csw/lib to bind against the CSW X11.  
Unfortunately
the problem could not be reproduced on the buildfarm and the exact cause
is yet unknown (James: correct me here if I'm wrong).
Keeping libs in /opt/csw/lib bound against SUNW X11 would keep existing
apps functioning and adding OpenCSW X11 libs in /opt/csw/X11/lib would
cleanly separate out libs.
I don't necessarily propagate this, but besides a lot of work it seems
clean and would minimize dependencies as apps that don't need OpenCSW  
X11
could bind to libs bound to SUNW X11.

> I'm not familiar with the initial problem (which called for the  
> OpenCSW X11), but I think this could get us digging ourselves deeper  
> into a hole instead of getting us out of it.
> I'm not saying that we should do it in either way, just that maybe  
> we should think about it some more before hasting into a solution  
> that might bite back at us later on.

Absolutely true. I made this first effort to get a better feeling how
much work it is and experiment with the layout. As I said I don't have
much expertise in that field and would prefer to follow someone who
has a good understanding of all issues.


Best regards

   -- Dago

From maciej at opencsw.org  Sat Apr 10 11:09:14 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sat, 10 Apr 2010 10:09:14 +0100
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com> 
	<1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>
Message-ID: <k2uce97543b1004100209r9c187e9j5fe7940768bf6bc6@mail.gmail.com>

2010/4/8 Ben Walton <bwalton at opencsw.org>:
> Excerpts from Maciej (Matchek) Blizinski's message of Thu Apr 08 12:05:02 -0400 2010:
>
>> file which is already provided by Python 2.6. ?I'm thinking of
>> implementing a check catching file collisions. ?Directories would be
>> excluded from the check. ?What do you think about such check?
>
> I think it's a great idea. ?As long as it's not too heavy, and I don't
> see why it would be, it should be a nice addition.

There might be a reason.  Currently, the data available to checkpkg are:

- the package set under examination
- /var/sadm/install/contents

I could easily implement a check that finds collisions against
packages installed on the buildfarm.  However, it would miss
collisions with packages that are not installed on the buildfarm.  In
this sense, Phil is right pointing at the package database; the
problem with that is that the package database is not available for
checkpkg, unless we want to tie checkpkg with the buildfarm, and I
think that we don't.

I think that we might add a new flag to checkpkg, that would point at
a specific catalog to include in the checks.

For example:

bin/checkpkg -c /export/mirror/opencsw/unstable/sparc/5.9 pkg1 pkg2 ...

This would make checkpkg verify whether it has the recent information
about all the packages from the catalog, and if there was anything
missing, it would get imported from the catalog, by unpacking each
package and collecting data from it.  The initial run might take
hours.

A central cache would certainly speed things up, but it has to be
something that can be also deployed outside of the buildfarm, so the
package database doesn't qualify.  Perhaps we could have a tool that
generates a file with the same format as /var/sadm/install/contents,
and checkpkg would take "additional /var/sadm/install/contents files"
as parameters:

bin/checkpkg/ \
    -c /var/sadm/install/contents \
    -c /opt/csw/share/install/contents \
    -c /home/maciej/mycontents \
    pkg1 pkg2 ...

The csw shared install/contents file could be generated from the
package database, if the database contains enough information.

This solution would require a party to take the responsibility of
updating the shared install/contents file, or else the check would not
be helpful.

Thoughts?

From benny at opencsw.org  Sat Apr 10 14:06:16 2010
From: benny at opencsw.org (Benjamin von Mossner)
Date: Sat, 10 Apr 2010 14:06:16 +0200
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <4BBF91B5.40906@opencsw.org>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
	<L0DsGt.KKM@cjsa.com> <4BBF8711.3080901@opencsw.org>
	<g2ld57eab941004091325i7f722717s943f966596d057fb@mail.gmail.com>
	<4BBF91B5.40906@opencsw.org>
Message-ID: <20100410120616.GA31919@vonmossner.de>

>> Please note: maintainers of xpdf and poppler will have to work
>> together, to agree which should be the "default" xpdf, if both
>> packages are installed.
> Regarding xpdf, there is no collision, its the utilities (pdftotext...)  
> that collide, which was why I suggested to Benny that he also split them  
> out to a separate package and we make them (poppler and xpdf_utils  
> incompatible).
I agree with Roger and as xpdf is already rebuilt and split, i would
suggest to go ahead and release it. Packages can be found in 
/home/testing and on bender. Or just have a look into the GAR 
recipe [1]

cheers,
benny

[1] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/xpdf/trunk/Makefile
-- 
/"\ ASCII RIBBON CAMPAIGN                  | Benjamin von Mossner
\ / AGAINST HTML MAIL                      | benny at vonmossner.de
 X  
/ \ multiple exclamation marks are a sure sign of a diseased mind

From bwalton at opencsw.org  Sat Apr 10 14:57:51 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 10 Apr 2010 08:57:51 -0400
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <k2uce97543b1004100209r9c187e9j5fe7940768bf6bc6@mail.gmail.com>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>
	<1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>
	<k2uce97543b1004100209r9c187e9j5fe7940768bf6bc6@mail.gmail.com>
Message-ID: <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Sat Apr 10 05:09:14 -0400 2010:

> A central cache would certainly speed things up, but it has to be
> something that can be also deployed outside of the buildfarm, so the
> package database doesn't qualify.  Perhaps we could have a tool that
> generates a file with the same format as /var/sadm/install/contents,
> and checkpkg would take "additional /var/sadm/install/contents
> files" as parameters:

Is the full /var/sadm/install/contents format required?  I'd expect
you only need the first and last fields to implement the check.  Eg:
File /x/y/z in your package CSWfoort conflicts with CSWoldfoo, or
something.

We have this info in the central database, as it's consumed by the
/search/ URL on the website.  If we made periodic (weekly?) dumps of
this data available for download/caching[1] by checkpkg, you could
achieve what's required, no?  It would be a public[1] URL, so it
wouldn't be tied to the buildfarm...

If this is deemed infeasible, then you're correct in the rest of what
you say.

Thanks
-Ben

[1] Maybe with a registered user/pass combo to prevent abuse.
    Consumers of the data could register to use it.
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bonivart at opencsw.org  Sun Apr 11 20:00:25 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 11 Apr 2010 20:00:25 +0200
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com> 
	<1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>
	<k2uce97543b1004100209r9c187e9j5fe7940768bf6bc6@mail.gmail.com>
	<1270903860-sup-1406@pinkfloyd.chass.utoronto.ca>
Message-ID: <j2v625385e31004111100z8154137m47ae3fadb4596160@mail.gmail.com>

On Sat, Apr 10, 2010 at 2:57 PM, Ben Walton <bwalton at opencsw.org> wrote:
> We have this info in the central database, as it's consumed by the
> /search/ URL on the website. ?If we made periodic (weekly?) dumps of
> this data available for download/caching[1] by checkpkg, you could
> achieve what's required, no? ?It would be a public[1] URL, so it
> wouldn't be tied to the buildfarm...

I also think this is the most reasonable approach. Add an option to
checkpkg to point it to the "contents" file. No complex
fetching/db-access code in checkpkg. Dump the file from the db with
simple scripts run from cron instead.

-- 
/peter

From ja at opencsw.org  Sun Apr 11 21:54:28 2010
From: ja at opencsw.org (Juergen Arndt)
Date: Sun, 11 Apr 2010 21:54:28 +0200
Subject: [csw-maintainers] Packages for nagios, nrpe and nsca in experimental
Message-ID: <C72D8387-0478-4317-A18C-2FFACCF615F5@opencsw.org>

Hello,

there are new packages for Nagios, NRPE and NSCA available from
http://mirror.opencsw.org/experimental.html#ja

Be aware that config files were moved to /etc/opt/csw - for Nagios this is not automatically done. You have to change the path names in your config files too. Look at [1] for more instructions.

Feedback is very welcome.

Juergen

[1] http://wiki.opencsw.org/nagios

-- 
Juergen Arndt


From maciej at opencsw.org  Mon Apr 12 01:19:22 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Mon, 12 Apr 2010 00:19:22 +0100
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com> 
	<1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>
	<k2uce97543b1004100209r9c187e9j5fe7940768bf6bc6@mail.gmail.com>
	<1270903860-sup-1406@pinkfloyd.chass.utoronto.ca>
Message-ID: <r2zce97543b1004111619hd1f4cbb9z1120aefa6618a690@mail.gmail.com>

2010/4/10 Ben Walton <bwalton at opencsw.org>:
> Is the full /var/sadm/install/contents format required?

If the file had the same format, I could use the same parser.

> I'd expect
> you only need the first and last fields to implement the check. ?Eg:
> File /x/y/z in your package CSWfoort conflicts with CSWoldfoo, or
> something.

I think that's OK if the file had dummy strings for uninteresting
fields.  The important fields are:

- full path
- file type
- pkgname

> We have this info in the central database, as it's consumed by the
> /search/ URL on the website. ?If we made periodic (weekly?) dumps of
> this data available for download/caching[1] by checkpkg, you could
> achieve what's required, no? ?It would be a public[1] URL, so it
> wouldn't be tied to the buildfarm...

I like the idea.  I'll try to sketch something along those lines in
the following week.

From bwalton at opencsw.org  Mon Apr 12 01:26:32 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 11 Apr 2010 19:26:32 -0400
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <r2zce97543b1004111619hd1f4cbb9z1120aefa6618a690@mail.gmail.com>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>
	<1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>
	<k2uce97543b1004100209r9c187e9j5fe7940768bf6bc6@mail.gmail.com>
	<1270903860-sup-1406@pinkfloyd.chass.utoronto.ca>
	<r2zce97543b1004111619hd1f4cbb9z1120aefa6618a690@mail.gmail.com>
Message-ID: <1271028334-sup-2527@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Sun Apr 11 19:19:22 -0400 2010:

> If the file had the same format, I could use the same parser.

Good point.

> I think that's OK if the file had dummy strings for uninteresting
> fields.  The important fields are:
> 
> - full path
> - file type
> - pkgname

I'm not sure if the db is carrying file type currently as I haven't
looked at it.  Can someone with familiarity comment on this?

> I like the idea.  I'll try to sketch something along those lines in
> the following week.

Cool!

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


From phil at bolthole.com  Mon Apr 12 06:42:25 2010
From: phil at bolthole.com (Philip Brown)
Date: Sun, 11 Apr 2010 21:42:25 -0700
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <1271028334-sup-2527@pinkfloyd.chass.utoronto.ca>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>
	<1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>
	<k2uce97543b1004100209r9c187e9j5fe7940768bf6bc6@mail.gmail.com>
	<1270903860-sup-1406@pinkfloyd.chass.utoronto.ca>
	<r2zce97543b1004111619hd1f4cbb9z1120aefa6618a690@mail.gmail.com>
	<1271028334-sup-2527@pinkfloyd.chass.utoronto.ca>
Message-ID: <v2ld57eab941004112142g2796a29bgc7fa3a78802deb7f@mail.gmail.com>

pleae note:
this weekend is my weekend to look after my children, so I've been rather busy.
however, after doing a little research , I have noticed two things:

1. there are existing, non-conflicting overlaps in sone packages that
make checks mote complicated
2. I need to reformat the database table that holds this stuff because
it needs to be case sensitive. Sigh.

this stuff will happen but it's going to take a few days

From phil at bolthole.com  Mon Apr 12 07:01:48 2010
From: phil at bolthole.com (Philip Brown)
Date: Sun, 11 Apr 2010 22:01:48 -0700
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <v2ld57eab941004112142g2796a29bgc7fa3a78802deb7f@mail.gmail.com>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>
	<1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>
	<k2uce97543b1004100209r9c187e9j5fe7940768bf6bc6@mail.gmail.com>
	<1270903860-sup-1406@pinkfloyd.chass.utoronto.ca>
	<r2zce97543b1004111619hd1f4cbb9z1120aefa6618a690@mail.gmail.com>
	<1271028334-sup-2527@pinkfloyd.chass.utoronto.ca>
	<v2ld57eab941004112142g2796a29bgc7fa3a78802deb7f@mail.gmail.com>
Message-ID: <o2pd57eab941004112201g1d268cd2s9ad70008f4485450@mail.gmail.com>

problem.
I can't seem to get our db to put the thing in case sensitive mode.
complains about every "_cs" or "_bin" character set I've tried so far

From bwalton at opencsw.org  Mon Apr 12 15:22:02 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 12 Apr 2010 09:22:02 -0400
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <o2pd57eab941004112201g1d268cd2s9ad70008f4485450@mail.gmail.com>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>
	<1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>
	<k2uce97543b1004100209r9c187e9j5fe7940768bf6bc6@mail.gmail.com>
	<1270903860-sup-1406@pinkfloyd.chass.utoronto.ca>
	<r2zce97543b1004111619hd1f4cbb9z1120aefa6618a690@mail.gmail.com>
	<1271028334-sup-2527@pinkfloyd.chass.utoronto.ca>
	<v2ld57eab941004112142g2796a29bgc7fa3a78802deb7f@mail.gmail.com>
	<o2pd57eab941004112201g1d268cd2s9ad70008f4485450@mail.gmail.com>
Message-ID: <1271078466-sup-8825@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Apr 12 01:01:48 -0400 2010:
> problem.
> I can't seem to get our db to put the thing in case sensitive mode.
> complains about every "_cs" or "_bin" character set I've tried so far

I've never been very fond of the mysql handling of collations etc.
It's caused me pain when I've had to play with it.

Can anyone that has had success with this help out?

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


From phil at bolthole.com  Mon Apr 12 18:03:59 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 12 Apr 2010 09:03:59 -0700
Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the
	recent ev.h conflict)
In-Reply-To: <o2pd57eab941004112201g1d268cd2s9ad70008f4485450@mail.gmail.com>
References: <n2vce97543b1004080905ud48618e6ud956a1b2058580df@mail.gmail.com>
	<1270743588-sup-5079@pinkfloyd.chass.utoronto.ca>
	<k2uce97543b1004100209r9c187e9j5fe7940768bf6bc6@mail.gmail.com>
	<1270903860-sup-1406@pinkfloyd.chass.utoronto.ca>
	<r2zce97543b1004111619hd1f4cbb9z1120aefa6618a690@mail.gmail.com>
	<1271028334-sup-2527@pinkfloyd.chass.utoronto.ca>
	<v2ld57eab941004112142g2796a29bgc7fa3a78802deb7f@mail.gmail.com>
	<o2pd57eab941004112201g1d268cd2s9ad70008f4485450@mail.gmail.com>
Message-ID: <j2rd57eab941004120903yd66aabfchdd3666f60bf4b3fd@mail.gmail.com>

On Sun, Apr 11, 2010 at 10:01 PM, Philip Brown <phil at bolthole.com> wrote:
> problem.
> I can't seem to get our db to put the thing in case sensitive mode.
> complains about every "_cs" or "_bin" character set I've tried so far
>

oh, PS: just to be explicit, the complaint is

ERROR 1115 (42000): Unknown character set: 'utf8_bin'

From phil at bolthole.com  Mon Apr 12 18:50:43 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 12 Apr 2010 09:50:43 -0700
Subject: [csw-maintainers] GAR, alternatives, and general integration of GAR
Message-ID: <m2od57eab941004120950y86577632ib92fa38a5e48dc4@mail.gmail.com>

So, I saw a recent mail, I think from Dagobert, about how to enable
"alternatives" use in GAR.
Unfortunately, I cant find the specific email, or I would quote it :(

But it brings up a side issue.

I have noticed in times past, a flaw in debian.
There has long been the framework of "debian helper", to help people
build debian packages. It gets more and more complicated over time.
And it has even gone through a few major re-workings, which were
semi-incompatible with older versions.

Like GAR, it was basically a layer on top of the "real" debian package
interface.

The problem is that people had to learn "debian helper", to use it,
and learning it ended up being almost as complicated as learning
direct debian packages... which means that people often ended up not
actually learning fully about the real debian package formats.

I see this happening with GAR. It is getting more and more complex....
and there is more of a movement for people to "learn gar", instead of
learning what is happening in our Actual Packages.

I see this as a bad thing.

I think that GAR should be an "assistant" to making packages, but not
a REPLACEMENT for understanding packages.

An excellent example, is the recent alternatives GAR module.

To my mind, using the gar module, is almost the same complexity as
just using alternatives directly!

To do it "directly"; provide ONE FILE, with ONE LINE in it.
basically:

/opt/csw/etc/alternatives/YOURPKGNAME:
/opt/csw/bin/userprog userprog /opt/csw/libexec/yourprog  {Priority rating}


then we do basically the same steps as if you were using a
'cswclassutil' function.
Set that file to be class "cswalternatives" in your prototype file,
add in cswalternatives to the CLASSES def in pkginfo, and depend on
the appropriate package (CSWalternatives).



It could be nice if GAR somehow auto-detected presense of
/opt/csw/etc/alternatives/[anything-here], and then automatically did
the class stuff.
However, it is not so nice, in my opinion, that it attempts to mask
the underlaying package mechanisms from the maintainer.
Maintainers need to understand how "alternatives" really functions, if
they are going to use it.

From dam at opencsw.org  Mon Apr 12 22:07:39 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 12 Apr 2010 22:07:39 +0200
Subject: [csw-maintainers] GAR, alternatives,
	and general integration of GAR
In-Reply-To: <m2od57eab941004120950y86577632ib92fa38a5e48dc4@mail.gmail.com>
References: <m2od57eab941004120950y86577632ib92fa38a5e48dc4@mail.gmail.com>
Message-ID: <42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org>

Hi Phil,

Am 12.04.2010 um 18:50 schrieb Philip Brown:
> So, I saw a recent mail, I think from Dagobert, about how to enable
> "alternatives" use in GAR.

This wiki-page?
   <http://sourceforge.net/apps/trac/gar/wiki/Alternatives>

> But it brings up a side issue.
>
> I have noticed in times past, a flaw in debian.
> There has long been the framework of "debian helper", to help people
> build debian packages. It gets more and more complicated over time.
> And it has even gone through a few major re-workings, which were
> semi-incompatible with older versions.
>
> Like GAR, it was basically a layer on top of the "real" debian package
> interface.
>
> The problem is that people had to learn "debian helper", to use it,
> and learning it ended up being almost as complicated as learning
> direct debian packages... which means that people often ended up not
> actually learning fully about the real debian package formats.
>
> I see this happening with GAR. It is getting more and more complex....
> and there is more of a movement for people to "learn gar", instead of
> learning what is happening in our Actual Packages.

In fact our package structure gets more and more complex, and GAR helps
*hiding* this complexity from the maintainer.

> I see this as a bad thing.


And this is a *good thing* as the maintainers is not forced to
understand every bit of it. If you are interested in something it
is of course better to understand it, but there is rarely the need.
The task of GAR is exactly hiding the ugly details like "how do
I assemble a package with 32/64 bit with isaexec" by condensing it
down to BUILD64=1.

Take Texinfo-files: To properly put them at the right location, set
the class for the texinfo-files, add the class in the correct order,
all this is done *without any intervention* from the maintainer.

> I think that GAR should be an "assistant" to making packages, but not
> a REPLACEMENT for understanding packages.
>
> An excellent example, is the recent alternatives GAR module.
>
> To my mind, using the gar module, is almost the same complexity as
> just using alternatives directly!

Funnily the only person complaining that this is too complex is
one of the few not using GAR.

> To do it "directly"; provide ONE FILE, with ONE LINE in it.
> basically:
>
> /opt/csw/etc/alternatives/YOURPKGNAME:
> /opt/csw/bin/userprog userprog /opt/csw/libexec/yourprog  {Priority  
> rating}

I don't see how this is different from the GAR implementation.
This is *exactly* of what you write in ALTERNATIVES_* in GAR.

> then we do basically the same steps as if you were using a
> 'cswclassutil' function.
> Set that file to be class "cswalternatives" in your prototype file,
> add in cswalternatives to the CLASSES def in pkginfo, and depend on
> the appropriate package (CSWalternatives).

All this is done automatically without maintainer intervention.

> It could be nice if GAR somehow auto-detected presense of
> /opt/csw/etc/alternatives/[anything-here], and then automatically did
> the class stuff.

GAR works exactly like that. If you feel like shooting yourself in
the left foot you can just put the file in the right location
manually and GAR will pick it up and take care of the rest.

> However, it is not so nice, in my opinion, that it attempts to mask
> the underlaying package mechanisms from the maintainer.
> Maintainers need to understand how "alternatives" really functions, if
> they are going to use it.

The understanding on how alternatives work has nothing to do on
how you specify it in the package. The current GAR implementation
is not even abstract enough: the final goal is to just specify
the alternative modulations and how they are build (like
"slang" and "ncurses") and what binaries should be switches
(like /opt/csw/bin/mutt) and GAR should take care of the rest
like renaming the real binaries, setting up the modulation etc.
so the current variables ALTERNATIVES_ would only be an
(then invisible) intermediate step.


Best regards

   -- Dago


From phil at bolthole.com  Mon Apr 12 22:38:00 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 12 Apr 2010 13:38:00 -0700
Subject: [csw-maintainers] GAR, alternatives,
	and general integration of 	GAR
In-Reply-To: <42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org>
References: <m2od57eab941004120950y86577632ib92fa38a5e48dc4@mail.gmail.com>
	<42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org>
Message-ID: <s2id57eab941004121338ic80adc58n89564ebea0752415@mail.gmail.com>

On Mon, Apr 12, 2010 at 1:07 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Phil,

*wave*

> Am 12.04.2010 um 18:50 schrieb Philip Brown:
>>
>> So, I saw a recent mail, I think from Dagobert, about how to enable
>> "alternatives" use in GAR.
>
> This wiki-page?
> ?<http://sourceforge.net/apps/trac/gar/wiki/Alternatives>

oops.. yes I think that was it.


>....
> And this is a *good thing* as the maintainers is not forced to
> understand every bit of it. If you are interested in something it
> is of course better to understand it, but there is rarely the need.
> The task of GAR is exactly hiding the ugly details like "how do
> I assemble a package with 32/64 bit with isaexec" by condensing it
> down to BUILD64=1.

Except of course, that we've had recent troubles of packages
inappropriately doing too much 64bit, and people not realizing how to
par that down :)

But in general, yes I think that's a good thing.
It's a nice, simple one line GAR thing.


> Take Texinfo-files: To properly put them at the right location, set
> the class for the texinfo-files, add the class in the correct order,
> all this is done *without any intervention* from the maintainer.

and this also I think is good. It doesnt require the maintainer to
particularly "learn gar".
Automatic, is good.


Unfortunately, it does not seem possible to make providing an
"alternatives" implementation in a package, "automatic".   or even
"simple".
That is what I am resisting here.

However,....  having thought about it some more, I think i've picked
up some missing pieces that you didnt explicitly say in your wiki
page, but may be true non the less.


You seem to be viewing it from a perspective of,
"I want to split up/recompile ONE software tarball, into multiple,
different-back-end packages".
Which IS actually somewhat complex, and I can see how that would
benefit from GAR assistance.

On the other hand, I am for some reason more focused on a view of
multiple maintainers, with their own package, and each compiles
something individually.
This may be unrealistic.

So, me going along with the idea of "Gar really does make this
easier".... would you please simplify your wiki page about it?

Right now, there are two, completely separate, examples. mostly
"code"(makefile), and not enough explaination.

MIght you move out the complicated automake stuff (or relegate it to a
"page 2" kind of thing, and then explain more what is going on with
the mutt exaple please?

From benny at opencsw.org  Mon Apr 12 22:41:26 2010
From: benny at opencsw.org (Benjamin von Mossner)
Date: Mon, 12 Apr 2010 22:41:26 +0200
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <20100410120616.GA31919@vonmossner.de>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
	<L0DsGt.KKM@cjsa.com> <4BBF8711.3080901@opencsw.org>
	<g2ld57eab941004091325i7f722717s943f966596d057fb@mail.gmail.com>
	<4BBF91B5.40906@opencsw.org> <20100410120616.GA31919@vonmossner.de>
Message-ID: <20100412204125.GB31919@vonmossner.de>

Hi,

> > Regarding xpdf, there is no collision, its the utilities (pdftotext...)  
> > that collide, which was why I suggested to Benny that he also split them  
> > out to a separate package and we make them (poppler and xpdf_utils  
> > incompatible).
> I agree with Roger and as xpdf is already rebuilt and split, i would
> suggest to go ahead and release it. Packages can be found in 
> /home/testing and on bender. Or just have a look into the GAR 
> recipe [1]
Phil, any answer on this? I know tha package is downgrade
but thats not a final solution, is it?

Cheers,
benny
-- 
/"\ ASCII RIBBON CAMPAIGN                  | Benjamin von Mossner
\ / AGAINST HTML MAIL                      | benny at vonmossner.de
 X  
/ \ multiple exclamation marks are a sure sign of a diseased mind

From phil at bolthole.com  Mon Apr 12 23:17:54 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 12 Apr 2010 14:17:54 -0700
Subject: [csw-maintainers] Upgrade problems??
In-Reply-To: <20100412204125.GB31919@vonmossner.de>
References: <L0C9x8.D0w@cjsa.com> <4BB83D49.20806@opencsw.org>
	<L0DsGt.KKM@cjsa.com> <4BBF8711.3080901@opencsw.org>
	<g2ld57eab941004091325i7f722717s943f966596d057fb@mail.gmail.com>
	<4BBF91B5.40906@opencsw.org> <20100410120616.GA31919@vonmossner.de>
	<20100412204125.GB31919@vonmossner.de>
Message-ID: <r2ld57eab941004121417j4c644bcbj954951d3fd8892cb@mail.gmail.com>

On Mon, Apr 12, 2010 at 1:41 PM, Benjamin von Mossner <benny at opencsw.org> wrote:
> Hi,
>
>> > Regarding xpdf, there is no collision, its the utilities (pdftotext...)
>> > that collide, which was why I suggested to Benny that he also split them
>> > out to a separate package and we make them (poppler and xpdf_utils
>> > incompatible).
>> I agree with Roger and as xpdf is already rebuilt and split, i would
>> suggest to go ahead and release it. Packages can be found in
>> /home/testing and on bender. Or just have a look into the GAR
>> recipe [1]
> Phil, any answer on this? I know tha package is downgrade
> but thats not a final solution, is it?
>

ah, sorry. lemme start a new thread on this thing, its getting a bit
long and ugly now :0

From phil at bolthole.com  Mon Apr 12 23:25:06 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 12 Apr 2010 14:25:06 -0700
Subject: [csw-maintainers] xpdf, poppler, going forward.
Message-ID: <m2yd57eab941004121425gd6c9983btb33b7afb1ad5e730@mail.gmail.com>

On Mon, Apr 12, 2010 at 1:41 PM, Benjamin von Mossner <benny at opencsw.org> wrote:

> Phil, any answer on this? I know tha package is downgrade
> but thats not a final solution, is it?
>

well, actually, Roger was nice enough to repackage soon after the downgrade.
So that part is handled.

However, now there is a question of, "how do we handle the rest of it?"

The issue at the core of this, is that it has been suggested that
(lib)poppler, if installed, makes for a "better" renderer than xpdf.

The thought, which both Dagobert and I have suggested, is that, if it
makes sense, you might repackage both xpdf, and the utils, to make use
of "alternatives", and then
xpdf would point to the "regular", xpdf implementation by default, but
then get auto-redirected to the poppler implementation, if that was
installed.

A few things have to happen, for that to be possible.

1. You would both have to AGREE "poppler is better" :)
2. you would move the xpdf binaries (both xpdf, and utils), to something like
    /opt/csw/libexec/xpdf/xxxxxx, and register all of then through
"alternatives"
3. Roger would do the same with the matching "poppler" binaries,
setting the "alternatives" priority as higher than the xpdf entries

4. you resubmit your stuff, he resubmits "CSWpoppler" (leaving
CSWlibpoppler unchanged)
and there we go.


However... if you disagree that poppler is always better... Then we
need to discuss further on here.

From maciej at opencsw.org  Tue Apr 13 19:21:17 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 13 Apr 2010 18:21:17 +0100
Subject: [csw-maintainers] cswcrontab action script vs the percent sign
Message-ID: <z2ice97543b1004131021o6b3e91d7r55c32a42f81dadb7@mail.gmail.com>

The cswcrontab CAS uses percent as if it was a comment.  However, the
percent is not a comment; the way cron works is it pipes everything
after the percent into the command being run.

More information: http://www.hcidata.info/crontab.htm

I think we need to mark the cswcrontab entries by a magic comment
above the crontab line.

Thoughts?

From phil at bolthole.com  Tue Apr 13 21:26:59 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 13 Apr 2010 12:26:59 -0700
Subject: [csw-maintainers] cswcrontab action script vs the percent sign
In-Reply-To: <z2ice97543b1004131021o6b3e91d7r55c32a42f81dadb7@mail.gmail.com>
References: <z2ice97543b1004131021o6b3e91d7r55c32a42f81dadb7@mail.gmail.com>
Message-ID: <s2vd57eab941004131226g7332d6ap8daf93334d5cf3e9@mail.gmail.com>

On Tue, Apr 13, 2010 at 10:21 AM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> The cswcrontab CAS uses percent as if it was a comment. ?However, the
> percent is not a comment; the way cron works is it pipes everything
> after the percent into the command being run.
>
> More information: http://www.hcidata.info/crontab.htm
>
> I think we need to mark the cswcrontab entries by a magic comment
> above the crontab line.
>
> Thoughts?
>

maybe the action needs to be reengineered entirely, to not depend on
comments like this at all.

Sun does have a few packages that tweak cron. I dont know how it
handles it, off-hand, but maybe we should emulate that more.

From dam at opencsw.org  Wed Apr 14 11:38:39 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 14 Apr 2010 11:38:39 +0200
Subject: [csw-maintainers] GAR, alternatives,
	and general integration of 	GAR
In-Reply-To: <s2id57eab941004121338ic80adc58n89564ebea0752415@mail.gmail.com>
References: <m2od57eab941004120950y86577632ib92fa38a5e48dc4@mail.gmail.com>
	<42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org>
	<s2id57eab941004121338ic80adc58n89564ebea0752415@mail.gmail.com>
Message-ID: <C2761625-1713-4595-8224-1C4DAC968C6D@opencsw.org>

Hi Phil,

Am 12.04.2010 um 22:38 schrieb Philip Brown:
>> ....
>> And this is a *good thing* as the maintainers is not forced to
>> understand every bit of it. If you are interested in something it
>> is of course better to understand it, but there is rarely the need.
>> The task of GAR is exactly hiding the ugly details like "how do
>> I assemble a package with 32/64 bit with isaexec" by condensing it
>> down to BUILD64=1.
>
> Except of course, that we've had recent troubles of packages
> inappropriately doing too much 64bit, and people not realizing how to
> par that down :)

This is about defaults, not hiding implementation details. That
only including libraries per default would be more intuitive may
be true and I already wanted to do it, but I fear breaking old
recipes. We may start another thread on how to best do this.

> Unfortunately, it does not seem possible to make providing an
> "alternatives" implementation in a package, "automatic".

I haven't done it "automatic" because I simply don't have enough
usecases. There is barey one package for each usecase and this
is just not enough for me to generalize out "the best default".

> or even "simple".

I have added an example for the most simple case: one alternative
in one package:
   <http://sourceforge.net/apps/trac/gar/wiki/Alternatives>
However, this also was not in there because there was no use for it.
The existing packages all use the other documented mechanisms.

> You seem to be viewing it from a perspective of,
> "I want to split up/recompile ONE software tarball, into multiple,
> different-back-end packages".
> Which IS actually somewhat complex, and I can see how that would
> benefit from GAR assistance.
>
> On the other hand, I am for some reason more focused on a view of
> multiple maintainers, with their own package, and each compiles
> something individually.
> This may be unrealistic.

Again, we didn't have that case up until now and I just added the
necessary line in GAR:
   <http://sourceforge.net/apps/trac/gar/changeset/9632>

> So, me going along with the idea of "Gar really does make this
> easier".... would you please simplify your wiki page about it?

Done.

> Right now, there are two, completely separate, examples. mostly
> "code"(makefile), and not enough explaination.
>
> MIght you move out the complicated automake stuff (or relegate it to a
> "page 2" kind of thing, and then explain more what is going on with
> the mutt exaple please?

We already have this documented in the general "How alternatives work"
wiki. As it is said on top of the trac wiki page you are supposed to
read that first. Every argument to GAR is exactly of what is passed
to alternatives with the --install added automatically.


Best regards

   -- Dago


From dam at opencsw.org  Wed Apr 14 11:46:13 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 14 Apr 2010 11:46:13 +0200
Subject: [csw-maintainers] cswcrontab action script vs the percent sign
In-Reply-To: <s2vd57eab941004131226g7332d6ap8daf93334d5cf3e9@mail.gmail.com>
References: <z2ice97543b1004131021o6b3e91d7r55c32a42f81dadb7@mail.gmail.com>
	<s2vd57eab941004131226g7332d6ap8daf93334d5cf3e9@mail.gmail.com>
Message-ID: <C6F514D8-CF2A-4CCA-9CF7-2CD26CA5F696@opencsw.org>

Hi,

Am 13.04.2010 um 21:26 schrieb Philip Brown:
> On Tue, Apr 13, 2010 at 10:21 AM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> The cswcrontab CAS uses percent as if it was a comment.  However, the
>> percent is not a comment; the way cron works is it pipes everything
>> after the percent into the command being run.
>>
>> More information: http://www.hcidata.info/crontab.htm
>>
>> I think we need to mark the cswcrontab entries by a magic comment
>> above the crontab line.
>>
>> Thoughts?

Looks like though...

> maybe the action needs to be reengineered entirely, to not depend on
> comments like this at all.
>
> Sun does have a few packages that tweak cron. I dont know how it
> handles it, off-hand, but maybe we should emulate that more.

Do you have an example for me or do I need to take SUNW* apart?


Best regards

   -- Dago


From maciej at opencsw.org  Wed Apr 14 14:20:58 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 14 Apr 2010 13:20:58 +0100
Subject: [csw-maintainers] Runpath menagerie for review
In-Reply-To: <4BAFB4EC.9000800@opencsw.org>
References: <ce97543b1003231327w5b0c2a8cj3437aa5f3874f7b9@mail.gmail.com> 
	<d57eab941003231425g283dd47gefe3633278841015@mail.gmail.com> 
	<ce97543b1003250309y13326c28sce84bc297c98041a@mail.gmail.com> 
	<d57eab941003250909vaa24152xbde18870986f9b22@mail.gmail.com> 
	<ce97543b1003261929i7b111aa4k96a3228d4a7b1a15@mail.gmail.com> 
	<4BAFB4EC.9000800@opencsw.org>
Message-ID: <o2hce97543b1004140520kd81a7196y62852419078a327@mail.gmail.com>

No dia 28 de Mar?o de 2010 20:58, Roger H?kansson <hson at opencsw.org> escreveu:
> Ok, that override works, but it seems like you could skip checking the
> override files...

True. I've added it to the todo list, but there are other tasks which
have priority:

- the whole catalog run (need to reduce the number of false positives
before release, need to replace the prototype with something that can
be used with the unmaintainable package database on the buildfarm)
- a bug in the stats collection of binary files (manifests itself with
the ivtools package and a number of others)
- file collision check (to prevent the kind of problems we had with ev.h)

From phil at bolthole.com  Wed Apr 14 18:16:10 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 14 Apr 2010 09:16:10 -0700
Subject: [csw-maintainers] cswcrontab action script vs the percent sign
In-Reply-To: <C6F514D8-CF2A-4CCA-9CF7-2CD26CA5F696@opencsw.org>
References: <z2ice97543b1004131021o6b3e91d7r55c32a42f81dadb7@mail.gmail.com>
	<s2vd57eab941004131226g7332d6ap8daf93334d5cf3e9@mail.gmail.com>
	<C6F514D8-CF2A-4CCA-9CF7-2CD26CA5F696@opencsw.org>
Message-ID: <p2nd57eab941004140916tdcb9fd15jdb66c9f6930c796f@mail.gmail.com>

On Wed, Apr 14, 2010 at 2:46 AM, Dagobert Michelsen <dam at opencsw.org> wrote:

>> Sun does have a few packages that tweak cron. I dont know how it
>> handles it, off-hand, but maybe we should emulate that more.
>
> Do you have an example for me or do I need to take SUNW* apart?
>

afraid that

grep cron SUNW*/install/postinstall


is your best option right now

From phil at bolthole.com  Wed Apr 14 18:23:40 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 14 Apr 2010 09:23:40 -0700
Subject: [csw-maintainers] GAR, alternatives,
	and general integration of 	GAR
In-Reply-To: <C2761625-1713-4595-8224-1C4DAC968C6D@opencsw.org>
References: <m2od57eab941004120950y86577632ib92fa38a5e48dc4@mail.gmail.com>
	<42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org>
	<s2id57eab941004121338ic80adc58n89564ebea0752415@mail.gmail.com>
	<C2761625-1713-4595-8224-1C4DAC968C6D@opencsw.org>
Message-ID: <m2ud57eab941004140923w4da62846h49ee08b69c63dc31@mail.gmail.com>

On Wed, Apr 14, 2010 at 2:38 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>
> I have added an example for the most simple case: one alternative
> in one package:
> ?<http://sourceforge.net/apps/trac/gar/wiki/Alternatives>

Thanks.


the page could still be a little clearer though.
The layout is currently an implicit flow of

- (pick one of the following)
- then, reguardless of which you pick, you should probably also do
this postinstall notice


The problem is that it doesnt explicitly call out "You only need to
pick ONE of the following three strategies."

Would be nice if you could make that a lot clearer somehow.

(in regular HTML pages, I tend to indent the whole set together. Not
sure whats the best way to handle it in wiki syntax)

From james at opencsw.org  Wed Apr 14 20:16:35 2010
From: james at opencsw.org (James Lee)
Date: Wed, 14 Apr 2010 18:16:35 GMT
Subject: [csw-maintainers] cswcrontab action script vs the percent sign
In-Reply-To: <C6F514D8-CF2A-4CCA-9CF7-2CD26CA5F696@opencsw.org>
References: <z2ice97543b1004131021o6b3e91d7r55c32a42f81dadb7@mail.gmail.com>
	<s2vd57eab941004131226g7332d6ap8daf93334d5cf3e9@mail.gmail.com>
	<C6F514D8-CF2A-4CCA-9CF7-2CD26CA5F696@opencsw.org>
Message-ID: <20100414.18163500.3907703497@gyor.oxdrove.co.uk>

On 14/04/10, 10:46:13, Dagobert Michelsen <dam at opencsw.org> wrote regarding 
Re: [csw-maintainers] cswcrontab action script vs the percent sign:

> > Sun does have a few packages that tweak cron. I dont know how it
> > handles it, off-hand, but maybe we should emulate that more.

> Do you have an example for me or do I need to take SUNW* apart?


http://docs.sun.com/app/docs/doc/805-6338/6j5vn5q5k



From dam at opencsw.org  Wed Apr 14 20:27:53 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 14 Apr 2010 20:27:53 +0200
Subject: [csw-maintainers] GAR, alternatives,
	and general integration of 	GAR
In-Reply-To: <m2ud57eab941004140923w4da62846h49ee08b69c63dc31@mail.gmail.com>
References: <m2od57eab941004120950y86577632ib92fa38a5e48dc4@mail.gmail.com>
	<42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org>
	<s2id57eab941004121338ic80adc58n89564ebea0752415@mail.gmail.com>
	<C2761625-1713-4595-8224-1C4DAC968C6D@opencsw.org>
	<m2ud57eab941004140923w4da62846h49ee08b69c63dc31@mail.gmail.com>
Message-ID: <D98F351F-A996-434C-8ACA-722527BC64B0@opencsw.org>

Hi Phil,

Am 14.04.2010 um 18:23 schrieb Philip Brown:
> On Wed, Apr 14, 2010 at 2:38 AM, Dagobert Michelsen  
> <dam at opencsw.org> wrote:
>>
>> I have added an example for the most simple case: one alternative
>> in one package:
>>  <http://sourceforge.net/apps/trac/gar/wiki/Alternatives>
>
> the page could still be a little clearer though.
> The layout is currently an implicit flow of
>
> - (pick one of the following)
> - then, reguardless of which you pick, you should probably also do
> this postinstall notice
>
> The problem is that it doesnt explicitly call out "You only need to
> pick ONE of the following three strategies."
>
> Would be nice if you could make that a lot clearer somehow.
>
> (in regular HTML pages, I tend to indent the whole set together. Not
> sure whats the best way to handle it in wiki syntax)

Umh, it looks pretty clear to me. As it is a wiki I suggest you just
make the change.


Best regards

   -- Dago


From phil at bolthole.com  Wed Apr 14 21:06:26 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 14 Apr 2010 12:06:26 -0700
Subject: [csw-maintainers] GAR, alternatives,
	and general integration of 	GAR
In-Reply-To: <D98F351F-A996-434C-8ACA-722527BC64B0@opencsw.org>
References: <m2od57eab941004120950y86577632ib92fa38a5e48dc4@mail.gmail.com>
	<42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org>
	<s2id57eab941004121338ic80adc58n89564ebea0752415@mail.gmail.com>
	<C2761625-1713-4595-8224-1C4DAC968C6D@opencsw.org>
	<m2ud57eab941004140923w4da62846h49ee08b69c63dc31@mail.gmail.com>
	<D98F351F-A996-434C-8ACA-722527BC64B0@opencsw.org>
Message-ID: <v2ud57eab941004141206o3085f1a5n8f50d79641bfa657@mail.gmail.com>

On Wed, Apr 14, 2010 at 11:27 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Phil,
>
>> The problem is that it doesnt explicitly call out "You only need to
>> pick ONE of the following three strategies."
>>
>> Would be nice if you could make that a lot clearer somehow.
>>
>> (in regular HTML pages, I tend to indent the whole set together. Not
>> sure whats the best way to handle it in wiki syntax)
>
> Umh, it looks pretty clear to me. As it is a wiki I suggest you just
> make the change.
>

"Not sure whats the best way to handle it in wiki syntax".
or for that matter, any way to handle it.

From dam at opencsw.org  Fri Apr 16 17:40:25 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 16 Apr 2010 17:40:25 +0200
Subject: [csw-maintainers] Updating all buildfarm servers now
Message-ID: <54E78005-9D49-4B46-AC75-C5930CACB901@opencsw.org>

Hi,

I am currently updating all buildfarm servers to current/. Please
stand by.


Best regards

   -- Dago

From dam at opencsw.org  Fri Apr 16 17:59:03 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 16 Apr 2010 17:59:03 +0200
Subject: [csw-maintainers] [csw-buildfarm] group request
In-Reply-To: <4BC887E3.6000601@cognigencorp.com>
References: <4BC78768.9070307@cognigencorp.com>
	<A2240212-D6D1-4041-8EAA-C2AFA2D83A8C@opencsw.org>
	<4BC87B62.7070405@cognigencorp.com>
	<83598AD0-0AC8-4C21-AD40-5194C40E85BF@opencsw.org>
	<4BC887E3.6000601@cognigencorp.com>
Message-ID: <EA85B675-5D34-45D9-93F9-CF4F02C6F5C8@opencsw.org>

Hi Darin,

(moving from buildfarm@ to maintainers@ is the topic is of general
interest).

Am 16.04.2010 um 17:53 schrieb Darin Perusich:

> Dago,
>
>>>
>>> I'm rebuilding with this option but I don't believe it's going to be
>>> adequate. The problem when setting --disable-installperms is the
>>> permission are then not properly set during 'make install' and the  
>>> user
>>> and group pairs in the prototype will not be properly setup, there  
>>> are
>>> some 90+ files/dirs which need to be amanda:sys.
>>>
>>> This is definitely a fakeroot problem on Solaris 9. I've tested the
>>> chown operation on Solaris 8 and 10 (w/ fakeroot built for sol10)  
>>> and
>>> it's functioning properly. I guess simply building on 8 will be the
>>> easiest way to get around this for now.
>>
>> Ok then, the Solaris 8 machines are still (and will be) remain in
>> place, so for now it should be ok. If you want to do a GAR build
>> later: GAR does not support fakeroot and fully relies on DESTDIR.
>> The prototype can then be adjusted programmatically with regular
>> expressions per field.
>
> If a package needs to set a large number of specific permission for
> users, groups, files, etc, having to adjust them individually w/ 
> regex's
> sounds overly complicated and error prone to me. What happens when a  
> new
> release is available and these change?

Then you must check the permissions. Usually, the changes are specific
to certain directories or specific binaries, so the level of change
should be manageable.

> In this instance amanda does fully support DESTDIR but you need to set
> some files to root:sys which are setgid, others amanda:sys, and others
> root:root. What would be the easiest way to accomplish this for a
> maintainer...using fakeroot, compiling as root to ensure user:groups  
> are
> properly set, or some ever changing regex's? I'm not looking for an
> answer, simply point out that these are complicated issues.

How does fakeroot work? Make a library interposer and grab the chown
calls? As the packaging processo can obviously not run as root I don't
see an easy alternative to manually setting permissions here - ideas
of course welcome!


Best regards

   -- Dago


From phil at bolthole.com  Fri Apr 16 19:37:00 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 16 Apr 2010 10:37:00 -0700
Subject: [csw-maintainers] [csw-buildfarm] group request
In-Reply-To: <EA85B675-5D34-45D9-93F9-CF4F02C6F5C8@opencsw.org>
References: <4BC78768.9070307@cognigencorp.com>
	<A2240212-D6D1-4041-8EAA-C2AFA2D83A8C@opencsw.org>
	<4BC87B62.7070405@cognigencorp.com>
	<83598AD0-0AC8-4C21-AD40-5194C40E85BF@opencsw.org>
	<4BC887E3.6000601@cognigencorp.com>
	<EA85B675-5D34-45D9-93F9-CF4F02C6F5C8@opencsw.org>
Message-ID: <v2yd57eab941004161037za4656bc6xd7907859e6418aa3@mail.gmail.com>

On Fri, Apr 16, 2010 at 8:59 AM, Dagobert Michelsen <dam at opencsw.org> wrote:

> How does fakeroot work? Make a library interposer and grab the chown
> calls?


yuyp. but it also intercepts the stat() calls somehow as well.

From ihsan at opencsw.org  Fri Apr 16 22:43:35 2010
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Fri, 16 Apr 2010 22:43:35 +0200
Subject: [csw-maintainers] checkpkg behavior
Message-ID: <4BC8CBF7.9020001@opencsw.org>

Hello,

I'm facing the problem that checkpkg behaves on x86 different than on sparc.

INFO:root:Collecting 'CSWirssi' package statistics.
Analyzing collected statistics...
CSWirssi:
# Missing dependencies of CSWirssi:
# If you don't know of any reasons to include these dependencies, you might
# remove them:
# ? CSWiconv
All modular tests were successful.


The following packages have been built:

  CSWirssi
/home/ihsan/staging/build-16.Apr.2010/irssi-0.8.15,REV=2010.04.16-SunOS5.9-sparc-CSW.pkg.gz

        [package] complete for irssi.


Everything is fine on sparc. If I build the same package on x86, this
will happen:

INFO:root:Collecting 'CSWirssi' package statistics.
Analyzing collected statistics...
CSWirssi:
# Missing dependencies of CSWirssi:
# If you don't know of any reasons to include these dependencies, you might
# remove them:
# ? CSWiconv
If any of the reported errors were false positives, you can
override them pasting the lines below to the GAR recipe.
CHECKPKG_OVERRIDES_CSWirssi +=
deprecated-library|opt/csw/bin/botti|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so
CHECKPKG_OVERRIDES_CSWirssi +=
deprecated-library|opt/csw/bin/irssi|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so
ERROR: Modular checks are reporting errors.
To run checkpkg in the debug mode, add the '-d' flag, for example:
After you modify any overrides, you need to do gmake remerge repackage
or gmake platforms-remerge platforms-repackage.
gmake: *** [pkgcheck] Error 2


What is going wrong here?




Ihsan
-- 
ihsan at dogan.ch		http://blog.dogan.ch/

From phil at bolthole.com  Fri Apr 16 23:05:12 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 16 Apr 2010 14:05:12 -0700
Subject: [csw-maintainers] checkpkg behavior
In-Reply-To: <4BC8CBF7.9020001@opencsw.org>
References: <4BC8CBF7.9020001@opencsw.org>
Message-ID: <r2ld57eab941004161405m314cfe6g8afbbff083fce4be@mail.gmail.com>

On Fri, Apr 16, 2010 at 1:43 PM, Ihsan Dogan <ihsan at opencsw.org> wrote:
> Hello,
>
> I'm facing the problem that checkpkg behaves on x86 different than on sparc.
>
> What is going wrong here?

I'm guessing that what is wrong, is that you compiled it differently,
on x86 vs sparc .

in one you linked in libiconv from csw, and in one, you didnt?
go check your make logs or Makefiles or something?

From maciej at opencsw.org  Fri Apr 16 23:17:46 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 16 Apr 2010 22:17:46 +0100
Subject: [csw-maintainers] checkpkg behavior
In-Reply-To: <4BC8CBF7.9020001@opencsw.org>
References: <4BC8CBF7.9020001@opencsw.org>
Message-ID: <w2sce97543b1004161417rced8aa3oac8cf6c91d9e4a75@mail.gmail.com>

No dia 16 de Abril de 2010 21:43, Ihsan Dogan <ihsan at opencsw.org> escreveu:
> I'm facing the problem that checkpkg behaves on x86 different than on sparc.

I don't know why the difference between x86 and sparc, but I can
explain what is the error about.

> CHECKPKG_OVERRIDES_CSWirssi +=
> deprecated-library|opt/csw/bin/botti|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so
> CHECKPKG_OVERRIDES_CSWirssi +=
> deprecated-library|opt/csw/bin/irssi|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so
> ERROR: Modular checks are reporting errors.

You're not supposed to link against Berkeley DB in /opt/csw/lib, it's
a legacy location.  Even though there is a symlink...

> ls -l /opt/csw/lib/libdb-4.7.so
lrwxrwxrwx   1 root     root          25 Nov 11 10:52
/opt/csw/lib/libdb-4.7.so -> ../bdb47/lib/libdb-4.7.so

...you're not supposed to link against it.  You need to give a
specific berkeley DB version in the runpath.  The symlink belongs to
the deprecated CSWbdb.  The actual library belongs to CSWbdb47.

In short, you need to prepend the RPATH list with /opt/csw/bdb47/lib.

From bwalton at opencsw.org  Sun Apr 18 02:06:16 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 17 Apr 2010 20:06:16 -0400
Subject: [csw-maintainers] coreutils
Message-ID: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>


Hi All,

I've finally gotten coreutils to a point where I think it's fit for
release.  This means that it's time to begin updating the packages
that depend on one or more of CSWgfile, CSWshutils and CSWtextutils.
Fortunately, this isn't a big list and the bulk of the packages have
active maintainers.

I've created a project page in the wiki to track this:
http://wiki.opencsw.org/project-coreutils

Briefly, the following people will need to be involved in updating
packages:

Maciej
Dago
Peter Felecan
Murray Jensen (listed active, but is this correct?)

If you see something in the wiki or package data that I've missed,
please let me know.

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


From ihsan at opencsw.org  Sun Apr 18 11:11:58 2010
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Sun, 18 Apr 2010 11:11:58 +0200
Subject: [csw-maintainers] Apache 2 Package
In-Reply-To: <4ADB45B0.1000207@opencsw.org>
References: <4ADB45B0.1000207@opencsw.org>
Message-ID: <4BCACCDE.7060807@opencsw.org>

Am 18.10.09 18:43, schrieb Ihsan Dogan:

> The Apache 2 package needs to be reworked and I can't find any
> additional ressources at this time. Would be great if someone could take
> over this package.

Still nobody interested in taking over Apache?




Ihsan

-- 
ihsan at dogan.ch		http://blog.dogan.ch/

From ihsan at opencsw.org  Sun Apr 18 13:17:51 2010
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Sun, 18 Apr 2010 13:17:51 +0200
Subject: [csw-maintainers] checkpkg behavior
In-Reply-To: <w2sce97543b1004161417rced8aa3oac8cf6c91d9e4a75@mail.gmail.com>
References: <4BC8CBF7.9020001@opencsw.org>
	<w2sce97543b1004161417rced8aa3oac8cf6c91d9e4a75@mail.gmail.com>
Message-ID: <4BCAEA5F.5010602@opencsw.org>

Am 16.04.10 23:17, schrieb Maciej (Matchek) Blizinski:

>> CHECKPKG_OVERRIDES_CSWirssi +=
>> deprecated-library|opt/csw/bin/botti|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so
>> CHECKPKG_OVERRIDES_CSWirssi +=
>> deprecated-library|opt/csw/bin/irssi|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so
>> ERROR: Modular checks are reporting errors.
> 
> You're not supposed to link against Berkeley DB in /opt/csw/lib, it's
> a legacy location.  Even though there is a symlink...

Thanks, I've fixed that now.



Ihsan

-- 
ihsan at dogan.ch		http://blog.dogan.ch/

From bonivart at opencsw.org  Sun Apr 18 14:34:06 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 18 Apr 2010 14:34:06 +0200
Subject: [csw-maintainers] coreutils
In-Reply-To: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
Message-ID: <l2n625385e31004180534i8228206t9128f3834d69916f@mail.gmail.com>

On Sun, Apr 18, 2010 at 2:06 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Murray Jensen (listed active, but is this correct?)

He quickly responded to my maintainer ping a few weeks back and said
he wants to remain listed as active but as he sometimes have little
time it's ok to take his packages if needed. I recommend you first ask
him directly though if he's interested in doing the update or not.

-- 
/peter

From bwalton at opencsw.org  Sun Apr 18 15:10:57 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 18 Apr 2010 09:10:57 -0400
Subject: [csw-maintainers] coreutils
In-Reply-To: <l2n625385e31004180534i8228206t9128f3834d69916f@mail.gmail.com>
References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
	<l2n625385e31004180534i8228206t9128f3834d69916f@mail.gmail.com>
Message-ID: <1271596236-sup-2073@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter Bonivart's message of Sun Apr 18 08:34:06 -0400 2010:

> He quickly responded to my maintainer ping a few weeks back and said
> he wants to remain listed as active but as he sometimes have little
> time it's ok to take his packages if needed. I recommend you first ask
> him directly though if he's interested in doing the update or not.

Ok.  I just mailed him directly.  Thanks for the info Peter.

-Ben

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


From bonivart at opencsw.org  Sun Apr 18 21:05:26 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 18 Apr 2010 21:05:26 +0200
Subject: [csw-maintainers] Apache 2 Package
In-Reply-To: <4BCACCDE.7060807@opencsw.org>
References: <4ADB45B0.1000207@opencsw.org> <4BCACCDE.7060807@opencsw.org>
Message-ID: <o2q625385e31004181205s26f2759au4b02eb2b28c0dabf@mail.gmail.com>

On Sun, Apr 18, 2010 at 11:11 AM, Ihsan Dogan <ihsan at opencsw.org> wrote:
> Am 18.10.09 18:43, schrieb Ihsan Dogan:
>
>> The Apache 2 package needs to be reworked and I can't find any
>> additional ressources at this time. Would be great if someone could take
>> over this package.
>
> Still nobody interested in taking over Apache?

Didn't Rupert do some work on it?

-- 
/peter

From maciej at opencsw.org  Mon Apr 19 09:58:28 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Mon, 19 Apr 2010 08:58:28 +0100
Subject: [csw-maintainers] coreutils
In-Reply-To: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
Message-ID: <n2sce97543b1004190058m54f8edcatd227306eaec4df5a@mail.gmail.com>

No dia 18 de Abril de 2010 01:06, Ben Walton <bwalton at opencsw.org> escreveu:
> I've finally gotten coreutils to a point where I think it's fit for
> release. ?This means that it's time to begin updating the packages
> that depend on one or more of CSWgfile, CSWshutils and CSWtextutils.

Do you mean that the packages formerly depending on CSWgfile and
friends should be now rebuild declaring a dependency on CSWcoreutils,
without CSWcoreutils being released?  This could be done with the
following override:

CHECKPKG_OVERRIDES_CSWwgetpaste += unidentified-dependency|CSWcoreutils

Here's an update to wgetpaste done in this way:
http://sourceforge.net/apps/trac/gar/changeset/9703

Maciej

From ihsan at opencsw.org  Mon Apr 19 11:39:10 2010
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Mon, 19 Apr 2010 11:39:10 +0200
Subject: [csw-maintainers] Apache 2 Package
In-Reply-To: <o2q625385e31004181205s26f2759au4b02eb2b28c0dabf@mail.gmail.com>
References: <4ADB45B0.1000207@opencsw.org> <4BCACCDE.7060807@opencsw.org>
	<o2q625385e31004181205s26f2759au4b02eb2b28c0dabf@mail.gmail.com>
Message-ID: <4BCC24BE.1080900@opencsw.org>

On 04/18/10 21:05, Peter Bonivart wrote:

>>> The Apache 2 package needs to be reworked and I can't find any
>>> additional ressources at this time. Would be great if someone could take
>>> over this package.
>> Still nobody interested in taking over Apache?
>
> Didn't Rupert do some work on it?

Not that I'm aware of.
Rupert?



Ihsan

-- 
ihsan at dogan.ch		http://blog.dogan.ch/

From bwalton at opencsw.org  Mon Apr 19 15:08:11 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 19 Apr 2010 09:08:11 -0400
Subject: [csw-maintainers] coreutils
In-Reply-To: <n2sce97543b1004190058m54f8edcatd227306eaec4df5a@mail.gmail.com>
References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
	<n2sce97543b1004190058m54f8edcatd227306eaec4df5a@mail.gmail.com>
Message-ID: <1271682347-sup-1053@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Mon Apr 19 03:58:28 -0400 2010:

> Do you mean that the packages formerly depending on CSWgfile and
> friends should be now rebuild declaring a dependency on CSWcoreutils,
> without CSWcoreutils being released?  This could be done with the
> following override:
> 
> CHECKPKG_OVERRIDES_CSWwgetpaste +=
> unidentified-dependency|CSWcoreutils

Yup. That's what I've been adding to the ones I've done already.  The
biggest holdup with by ruby_dev as I can't rebuild that package until
the gcc stuff is sorted out[1].  If it drags on too long, I may unroll
the package and hand-edit the dependency just to get coreutils out.

> Here's an update to wgetpaste done in this way:
> http://sourceforge.net/apps/trac/gar/changeset/9703

That looks good.

Thanks
-Ben

[1] I've nominally started looking at gcc (4.5.0 was just released)
    but that will need some updates to other packages.... :)
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From rupert at opencsw.org  Mon Apr 19 18:22:13 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Mon, 19 Apr 2010 18:22:13 +0200
Subject: [csw-maintainers] Apache 2 Package
In-Reply-To: <4BCC24BE.1080900@opencsw.org>
References: <4ADB45B0.1000207@opencsw.org> <4BCACCDE.7060807@opencsw.org> 
	<o2q625385e31004181205s26f2759au4b02eb2b28c0dabf@mail.gmail.com> 
	<4BCC24BE.1080900@opencsw.org>
Message-ID: <u2q6af4271004190922p40994628r576f5b1483b3b9d4@mail.gmail.com>

On Mon, Apr 19, 2010 at 11:39, Ihsan Dogan <ihsan at opencsw.org> wrote:
> On 04/18/10 21:05, Peter Bonivart wrote:
>
>>>> The Apache 2 package needs to be reworked and I can't find any
>>>> additional ressources at this time. Would be great if someone could take
>>>> over this package.
>>>
>>> Still nobody interested in taking over Apache?
>>
>> Didn't Rupert do some work on it?
>
> Not that I'm aware of.
> Rupert?

maciej, and me did some yes .. but this was far from good. now there
is only one single package contrary to the sophisticated setup before.
a package of version 2.2.14 is on
http://mirror.opencsw.org/testing.html.

rupert

From phil at bolthole.com  Mon Apr 19 19:06:17 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 19 Apr 2010 10:06:17 -0700
Subject: [csw-maintainers] Apache 2 Package
In-Reply-To: <u2q6af4271004190922p40994628r576f5b1483b3b9d4@mail.gmail.com>
References: <4ADB45B0.1000207@opencsw.org> <4BCACCDE.7060807@opencsw.org>
	<o2q625385e31004181205s26f2759au4b02eb2b28c0dabf@mail.gmail.com>
	<4BCC24BE.1080900@opencsw.org>
	<u2q6af4271004190922p40994628r576f5b1483b3b9d4@mail.gmail.com>
Message-ID: <z2xd57eab941004191006w29b44001s6f147a1ec48eda71@mail.gmail.com>

On Mon, Apr 19, 2010 at 9:22 AM, rupert THURNER <rupert at opencsw.org> wrote:
>
>
> maciej, and me did some yes .. but this was far from good. now there
> is only one single package contrary to the sophisticated setup before.
> a package of version 2.2.14 is on
> http://mirror.opencsw.org/testing.html.
>

might be better if you at least split out the manual, judging by size:

bender$ ls -Ll apache2*
-rw-rw-r--   2 phil     release     9146 Aug 25  2009
apache2-2.2.13,REV=2009.08.22-SunOS5.8-all-CSW.pkg.gz
-rw-rw-r--   1 phil     release   532528 Aug 25  2009
apache2_devel-2.2.13,REV=2009.08.22-SunOS5.8-sparc-CSW.pkg.gz
-rw-rw-r--   2 phil     release  2351496 Aug 25  2009
apache2_manual-2.2.13,REV=2009.08.22-SunOS5.8-all-CSW.pkg.gz
-rw-rw-r--   1 phil     release   804890 Aug 25  2009
apache2c-2.2.13,REV=2009.08.22-SunOS5.8-sparc-CSW.pkg.gz
-rw-rw-r--   1 phil     release   206820 Aug 25  2009
apache2rt-2.2.13,REV=2009.08.22-SunOS5.8-sparc-CSW.pkg.gz

From phil at bolthole.com  Mon Apr 19 19:08:03 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 19 Apr 2010 10:08:03 -0700
Subject: [csw-maintainers] coreutils
In-Reply-To: <n2sce97543b1004190058m54f8edcatd227306eaec4df5a@mail.gmail.com>
References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
	<n2sce97543b1004190058m54f8edcatd227306eaec4df5a@mail.gmail.com>
Message-ID: <y2md57eab941004191008x6628562bs1f7a5a7618bee877@mail.gmail.com>

On Mon, Apr 19, 2010 at 12:58 AM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
>
> Do you mean that the packages formerly depending on CSWgfile and
> friends should be now rebuild declaring a dependency on CSWcoreutils,
> without CSWcoreutils being released?


well, it doesnt have to be an "all at once" operation, if coredutils
is just released with some dummy CSWgfile packages that depend on
CSWcoreutils.

From bwalton at opencsw.org  Mon Apr 19 19:25:36 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 19 Apr 2010 13:25:36 -0400
Subject: [csw-maintainers] coreutils
In-Reply-To: <y2md57eab941004191008x6628562bs1f7a5a7618bee877@mail.gmail.com>
References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
	<n2sce97543b1004190058m54f8edcatd227306eaec4df5a@mail.gmail.com>
	<y2md57eab941004191008x6628562bs1f7a5a7618bee877@mail.gmail.com>
Message-ID: <1271697460-sup-321@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Apr 19 13:08:03 -0400 2010:

> well, it doesnt have to be an "all at once" operation, if coredutils
> is just released with some dummy CSWgfile packages that depend on
> CSWcoreutils.

No, I think it does, unfortunately...if we want to keep circular
dependencies out of the catalog, anyway.

We could do:

CSWgfile(dummy) -> {CSWcoreutils,CSWshutils,CSWtextutils}
CSWshutils(dummy) -> {CSWcoreutils,CSWgfile,CSWtextutils}
CSWtextutils(dummy) -> {CSWcoreutils,CSWgfile,CSWshutils}

Each of the old packages would need to depend on coreutils _and_ the
other two dummy packages to force an update of one to update the
others too.

This would also imply that CSWcoreutils couldn't declare itself
Incompatible with the old packages which opens us up to:

Someone updates CSWwgetpaste (depends on CSWshutils) when Maciej
cranks out a new version, but doesn't update any packages that depend
on CSWgfile or CSWtextutils.  Those would be left in their current
(file bearing) states and would then have file conflicts with
CSWcoreutils.  A full 'upgrade' operation would handle this, but there
are situations where even adding one of the affected packages could
trigger the above behaviour.

Thoughts?

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


From rupert at opencsw.org  Mon Apr 19 21:06:48 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Mon, 19 Apr 2010 21:06:48 +0200
Subject: [csw-maintainers] apr compile failed on i386
In-Reply-To: <m2j6af4271004191205ia79e19c9p38e75d940e228af8@mail.gmail.com>
References: <m2j6af4271004191205ia79e19c9p38e75d940e228af8@mail.gmail.com>
Message-ID: <z2p6af4271004191206i6c0cecbarb6ccbc271e1953a@mail.gmail.com>

a "gmake platforms-reinstall platforms-remerge platforms-repackage"

led to the following error:

/home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share
/home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1
/home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1/mkdir.sh
/home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1/libtool
/home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1/apr_rules.mk
/home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1/make_exports.awk
/home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1/make_var_export.awk
gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk'
gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk'
[ Reset install state for modulation isa-amd64: ISA=amd64 ]
gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk'
gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk'
gar/gar.conf.mk:418: *** The ISA 'amd64' can not be build on this
kernel with the arch 'i386'. ?Stop.
gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk'
gmake: *** [reset-install-isa-amd64] Error 2
gmake: Leaving directory `/home/rupert/mgar/pkg/apr/trunk'
Connection to current9x closed.
gmake: *** [platforms-reinstall] Error 2

is this in apr, or in gar?

rupert.

From phil at bolthole.com  Mon Apr 19 21:18:26 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 19 Apr 2010 12:18:26 -0700
Subject: [csw-maintainers] coreutils
In-Reply-To: <1271697460-sup-321@pinkfloyd.chass.utoronto.ca>
References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
	<n2sce97543b1004190058m54f8edcatd227306eaec4df5a@mail.gmail.com>
	<y2md57eab941004191008x6628562bs1f7a5a7618bee877@mail.gmail.com>
	<1271697460-sup-321@pinkfloyd.chass.utoronto.ca>
Message-ID: <s2td57eab941004191218w89244112h3e52f7d940aceb4f@mail.gmail.com>

On Mon, Apr 19, 2010 at 10:25 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon Apr 19 13:08:03 -0400 2010:
>
>> well, it doesnt have to be an "all at once" operation, if coredutils
>> is just released with some dummy CSWgfile packages that depend on
>> CSWcoreutils.
>
> No, I think it does, unfortunately...if we want to keep circular
> dependencies out of the catalog, anyway.
>....
>...

> Thoughts?
>

drat. I think you're right.

From dam at opencsw.org  Mon Apr 19 21:56:27 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 19 Apr 2010 21:56:27 +0200
Subject: [csw-maintainers] apr compile failed on i386
In-Reply-To: <z2p6af4271004191206i6c0cecbarb6ccbc271e1953a@mail.gmail.com>
References: <m2j6af4271004191205ia79e19c9p38e75d940e228af8@mail.gmail.com>
	<z2p6af4271004191206i6c0cecbarb6ccbc271e1953a@mail.gmail.com>
Message-ID: <F0FBC425-E351-4146-BB6E-5BB6839D18B5@opencsw.org>

Hi Rupert,

Am 19.04.2010 um 21:06 schrieb rupert THURNER:
> a "gmake platforms-reinstall platforms-remerge platforms-repackage"
>
> led to the following error:
>
> /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ 
> share
> /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ 
> share/build-1
> /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ 
> share/build-1/mkdir.sh
> /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ 
> share/build-1/libtool
> /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ 
> share/build-1/apr_rules.mk
> /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ 
> share/build-1/make_exports.awk
> /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ 
> share/build-1/make_var_export.awk
> gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk'
> gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk'
> [ Reset install state for modulation isa-amd64: ISA=amd64 ]
> gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk'
> gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk'
> gar/gar.conf.mk:418: *** The ISA 'amd64' can not be build on this
> kernel with the arch 'i386'.  Stop.
> gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk'
> gmake: *** [reset-install-isa-amd64] Error 2
> gmake: Leaving directory `/home/rupert/mgar/pkg/apr/trunk'
> Connection to current9x closed.
> gmake: *** [platforms-reinstall] Error 2
>
> is this in apr, or in gar?

This is a GAR issue. I can't see the cause right now and rebuild apr to
reproduce your problem and look into it.


Best regards

   -- Dago

From rupert at opencsw.org  Wed Apr 21 00:10:18 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Wed, 21 Apr 2010 00:10:18 +0200
Subject: [csw-maintainers] java error, core dumped, when building bdb50,
	subversion-1.6.11
In-Reply-To: <t2x6af4271004201243y91c87bebyfd015e9a5849c866@mail.gmail.com>
References: <t2x6af4271004201243y91c87bebyfd015e9a5849c866@mail.gmail.com>
Message-ID: <n2x6af4271004201510x5ab6f727z4ad31c599852ac45@mail.gmail.com>

when compiling subversion-1.6.11 a similar error occurred than with bdb50:

/src/org/tigris/subversion/javahl/Version.java
/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.11/subversion/bindings/javahl/src/org/tigris/subversion/javahl/ChangelistCallback.java
/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.11/subversion/bindings/javahl/src/org/tigris/subversion/javahl/SVNClient.java
/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.11/subversion/bindings/javahl/src/org/tigris/subversion/javahl/NativeException.java
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# ?Internal Error (4F533F534F4C415249533F53504152430E4350500054 FF),
pid=12617, tid=1
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_15-b04 mixed mode)
# An error report file with more information is saved as hs_err_pid12617.log
gmake[3]: *** [subversion/bindings/javahl/classes/org/tigris/subversion/javahl/PropertyData.class]
Illegal Instruction (core dumped)
gmake[3]: Leaving directory
`/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.11'
gmake[2]: *** [svn-java] Error 2
gmake[2]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk'
gmake[1]: *** [merge-isa-sparcv8] Error 2
gmake[1]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk'
gmake: *** [platforms] Error 2
rupert at current9s ~/mgar/pkg/subversion/trunk

can it be that the build system now mixes up the various java versions
installed?

kr, rupert


On Mon, Apr 5, 2010 at 21:20, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Rupert,
>
> Am 03.04.2010 um 15:33 schrieb rupert THURNER:
>
>> hi,
>>
>> while the little one was sleeping i tried to give bdb-50 a try ....
>> and i could not even compile it:
>>
>> ./work/solaris9-sparc/build-isa-sparcv8/db-5.0.21/build_unix/config.log ?says:
>>
>> configure:16889: checking for javac
>> configure:16905: found /usr/jdk1.6.0_07/bin/javac
>> configure:16916: result: javac
>> configure:16974: checking if javac works
>> configure:16988: javac ?Test.java
>> configure:16991: $? = 0
>> configure:17002: result: yes
>> configure:17012: checking for jar
>> configure:17028: found /usr/jdk1.6.0_07/bin/jar
>> configure:17039: result: jar
>> configure:17103: checking for java
>> configure:17119: found /usr/jdk1.6.0_07/bin/java
>> configure:17130: result: java
>> configure:17190: checking for uudecode
>> configure:17206: found /usr/bin/uudecode
>> configure:17217: result: yes
>> configure:17226: checking if uudecode can decode base 64 file
>> configure: 17249: uudecode had trouble decoding base 64 file 'Test.uue'
>> configure: failed file was:
>> begin-base64 644 Test.class
>> yv66vgADAC0AFQcAAgEABFRlc3QHAAQBABBqYXZhL2xhbmcvT2JqZWN0AQAE
>> bWFpbgEAFihbTGphdmEvbGFuZy9TdHJpbmc7KVYBAARDb2RlAQAPTGluZU51
>> bWJlclRhYmxlDAAKAAsBAARleGl0AQAEKEkpVgoADQAJBwAOAQAQamF2YS9s
>> YW5nL1N5c3RlbQEABjxpbml0PgEAAygpVgwADwAQCgADABEBAApTb3VyY2VG
>> aWxlAQAJVGVzdC5qYXZhACEAAQADAAAAAAACAAkABQAGAAEABwAAACEAAQAB
>> AAAABQO4AAyxAAAAAQAIAAAACgACAAAACgAEAAsAAQAPABAAAQAHAAAAIQAB
>> AAEAAAAFKrcAErEAAAABAAgAAAAKAAIAAAAEAAQABAABABMAAAACABQ=
>> ====
>> configure:17253: result: no
>> configure:17258: WARNING: I have to compile Test.class from scratch
>> configure:17389: checking if java works
>> configure:17407: javac ?Test.java
>> configure:17410: $? = 0
>> configure:17420: java ?Test
>> ../dist/configure: line 1: 28337 Illegal Instruction ? ? (core dumped)
>> $JAVA $JAVAFLAGS $TEST
>> configure:17423: $? = 132
>> configure: failed program was:
>> /* [#]line 17402 "configure" */
>> public class Test {
>> public static void main (String args[]) {
>> ? ? ? ?System.exit (0);
>> } }
>> configure:17429: error: The Java VM java failed (see config.log, check
>> the CLASSPATH?)
>>
>>
>> did you see something similar already?
>
> No, maybe you try some other JVM?
>
>
> Best regards
>
> ?-- Dago
>
>

From dam at opencsw.org  Wed Apr 21 10:07:58 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 21 Apr 2010 10:07:58 +0200
Subject: [csw-maintainers] apr compile failed on i386
In-Reply-To: <F0FBC425-E351-4146-BB6E-5BB6839D18B5@opencsw.org>
References: <m2j6af4271004191205ia79e19c9p38e75d940e228af8@mail.gmail.com>
	<z2p6af4271004191206i6c0cecbarb6ccbc271e1953a@mail.gmail.com>
	<F0FBC425-E351-4146-BB6E-5BB6839D18B5@opencsw.org>
Message-ID: <651DF211-DD52-4AA0-8F2E-67A3AF9987B5@opencsw.org>

Hi Rupert,

Am 19.04.2010 um 21:56 schrieb Dagobert Michelsen:
> This is a GAR issue. I can't see the cause right now and rebuild apr  
> to
> reproduce your problem and look into it.

Sorry, I can not reproduce it. Does it still occur for you?


Best regards

   -- Dago

From maciej at opencsw.org  Wed Apr 21 14:26:45 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 21 Apr 2010 13:26:45 +0100
Subject: [csw-maintainers] Calling statvfs() on my home directory
Message-ID: <k2zce97543b1004210526y866c8bf8vb47cfcc74a282cdc@mail.gmail.com>

While debugging a failed OpenCSW package build on my workstation I
came across a problem with statvfs() returning EOVERFLOW.  I did some
experiments, and ended up writing the following example code, which
makes a dummy statvfs() call and reports whether it has succeeded or
not.  I've compiled it in two versions, the sole difference being -m32
vs -m64.  Here's the complete code:

$ cat statvfs-example.sh
cat > statvfs-example.c <<EOF
#include <stdio.h>
#include <stdlib.h>
#include <sys/statvfs.h>
#include <errno.h>

int main(void) {
  struct statvfs buf;
  extern int errno;
  if (statvfs(getenv("HOME"), &buf) < 0) {
    printf("statvfs() has failed, errno = %d\n", errno);
    switch (errno) {
      case EOVERFLOW:
        printf("EOVERFLOW\n");
        break;
    }
  } else {
    printf("statvfs() completed successfully.\n");
  }
  exit(EXIT_SUCCESS);
}
EOF

for word_length in 32 64; do
  cc \
    -m${word_length} \
    statvfs-example.c \
    -o statvfs-example-${word_length}
  file statvfs-example-${word_length}
  ./statvfs-example-${word_length}
done

Running it yields the following:

$ bash statvfs-example.sh
statvfs-example-32:     ELF 32-bit LSB executable 80386 Version 1
[FPU], dynamically linked, not stripped
statvfs() has failed, errno = 79
EOVERFLOW
statvfs-example-64:     ELF 64-bit LSB executable AMD64 Version 1 [SSE
FXSR FPU], dynamically linked, not stripped
statvfs() completed successfully.

It looks like any 32-bit binary making the statvfs() call on my home
directory will fail with EOVERFLOW, while a 64-bit binary will
succeed.

Does that count as an advantage of building 64-bit binaries?

From maciej at opencsw.org  Wed Apr 21 15:06:54 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 21 Apr 2010 14:06:54 +0100
Subject: [csw-maintainers] Calling statvfs() on my home directory
In-Reply-To: <k2zce97543b1004210526y866c8bf8vb47cfcc74a282cdc@mail.gmail.com>
References: <k2zce97543b1004210526y866c8bf8vb47cfcc74a282cdc@mail.gmail.com>
Message-ID: <r2oce97543b1004210606tc38823earc0bcbededaeffb51@mail.gmail.com>

As Dago suggested, adding the output of getconf LFS_CFLAGS to CFLAGS
fixes the statvfs() issue.  It expands to:

-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

Outcome:

Running: cc -m32 statvfs-example.c -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -o statvfs-example-32
statvfs-example-32:     ELF 32-bit LSB executable 80386 Version 1
[FPU], dynamically linked, not stripped
statvfs() completed successfully.
Running: cc -m64 statvfs-example.c -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -o statvfs-example-64
statvfs-example-64:     ELF 64-bit LSB executable AMD64 Version 1 [SSE
FXSR FPU], dynamically linked, not stripped
statvfs() completed successfully.

I don't yet have a proof, but I think that our perl might not handle
statvfs() well.  Does anyone know what perl functionality causes the
statvfs() call to be made?

From Darin.Perusich at cognigencorp.com  Fri Apr 23 17:42:05 2010
From: Darin.Perusich at cognigencorp.com (Darin Perusich)
Date: Fri, 23 Apr 2010 11:42:05 -0400
Subject: [csw-maintainers] installing packages on the "testing" hosts
Message-ID: <4BD1BFCD.50802@cognigencorp.com>

Is it possible to install packages on testing hosts? I use to be able to
ssh as root over to them but am unable to now. I'm trying to figure out
a problem with the new amanda package I'm building and being able to
install in on something other solaris 10 would be helpful.

-- 
Darin Perusich
Unix Systems Administrator
Cognigen Corporation
395 Youngs Rd.
Williamsville, NY 14221
Phone: 716-633-3463
Email: darinper at cognigencorp.com

From rupert at opencsw.org  Fri Apr 23 19:55:45 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Fri, 23 Apr 2010 19:55:45 +0200
Subject: [csw-maintainers] apr compile failed on i386
In-Reply-To: <651DF211-DD52-4AA0-8F2E-67A3AF9987B5@opencsw.org>
References: <m2j6af4271004191205ia79e19c9p38e75d940e228af8@mail.gmail.com> 
	<z2p6af4271004191206i6c0cecbarb6ccbc271e1953a@mail.gmail.com> 
	<F0FBC425-E351-4146-BB6E-5BB6839D18B5@opencsw.org>
	<651DF211-DD52-4AA0-8F2E-67A3AF9987B5@opencsw.org>
Message-ID: <z2v6af4271004231055kc95f20bcr714600c679191516@mail.gmail.com>

On Wed, Apr 21, 2010 at 10:07, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Rupert,
>
> Am 19.04.2010 um 21:56 schrieb Dagobert Michelsen:
>>
>> This is a GAR issue. I can't see the cause right now and rebuild apr to
>> reproduce your problem and look into it.
>
> Sorry, I can not reproduce it. Does it still occur for you?
>

no - cannot reproduce with a clean build.

rupert.

From Darin.Perusich at cognigencorp.com  Fri Apr 23 21:50:32 2010
From: Darin.Perusich at cognigencorp.com (Darin Perusich)
Date: Fri, 23 Apr 2010 15:50:32 -0400
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
Message-ID: <4BD1FA08.2090106@cognigencorp.com>

Hello,

I'm testing a new Amanda package and all the apps are core dumping and
for some reason they are opening both the 32 and 64bit
libgthread-2.0.so.0 libraries. Has anyone ever seen this or have any
idea why it might be happening?

When I truss execution you can see that both libs are being opened.

root at testing9s : grep open /tmp/truss.out | grep -v NOENT | grep gthread
open("/opt/csw/lib/libgthread-2.0.so.0", O_RDONLY) = 5
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5

The error I get just before it dumps core is:

ERROR:glib-util.c:48:glib_init: assertion failed: (!g_thread_supported())

Line 48 of glib-util.c is wrapped in a libcurl definition so I'm
wondering if this could be related to libcurl.

#ifdef HAVE_LIBCURL
# ifdef G_THREADS_ENABLED
    g_assert(!g_thread_supported());
# endif
    g_assert(curl_global_init(CURL_GLOBAL_ALL) == 0);
#endif


-- 
Darin Perusich
Unix Systems Administrator
Cognigen Corporation
395 Youngs Rd.
Williamsville, NY 14221
Phone: 716-633-3463
Email: darinper at cognigencorp.com

From phil at bolthole.com  Fri Apr 23 23:25:29 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 23 Apr 2010 14:25:29 -0700
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
In-Reply-To: <4BD1FA08.2090106@cognigencorp.com>
References: <4BD1FA08.2090106@cognigencorp.com>
Message-ID: <j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>

On Fri, Apr 23, 2010 at 12:50 PM, Darin Perusich
<Darin.Perusich at cognigencorp.com> wrote:
> Hello,
>
> I'm testing a new Amanda package and all the apps are core dumping and
> for some reason they are opening both the 32 and 64bit
> libgthread-2.0.so.0 libraries. Has anyone ever seen this or have any
> idea why it might be happening?

I believe that

LD_DEBUG=files /run/your/app


lets you know exactly why a particular shared lib is loaded.

it might be that two different components of your dependancy tree, are
pulling in two different versions of the "same" library?

From Darin.Perusich at cognigencorp.com  Sat Apr 24 01:32:26 2010
From: Darin.Perusich at cognigencorp.com (Darin.Perusich at cognigencorp.com)
Date: Fri, 23 Apr 2010 19:32:26 -0400 (EDT)
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
In-Reply-To: <j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>
References: <4BD1FA08.2090106@cognigencorp.com>
	<j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>
Message-ID: <40919.69.207.26.168.1272065546.squirrel@onestop.cognigencorp.com>

Thanks Phil, this should be very helpful.

> On Fri, Apr 23, 2010 at 12:50 PM, Darin Perusich
> <Darin.Perusich at cognigencorp.com> wrote:
>> Hello,
>>
>> I'm testing a new Amanda package and all the apps are core dumping and
>> for some reason they are opening both the 32 and 64bit
>> libgthread-2.0.so.0 libraries. Has anyone ever seen this or have any
>> idea why it might be happening?
>
> I believe that
>
> LD_DEBUG=files /run/your/app
>
>
> lets you know exactly why a particular shared lib is loaded.
>
> it might be that two different components of your dependancy tree, are
> pulling in two different versions of the "same" library?
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>


From Darin.Perusich at cognigencorp.com  Sat Apr 24 01:42:28 2010
From: Darin.Perusich at cognigencorp.com (Darin.Perusich at cognigencorp.com)
Date: Fri, 23 Apr 2010 19:42:28 -0400 (EDT)
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
In-Reply-To: <j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>
References: <4BD1FA08.2090106@cognigencorp.com>
	<j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>
Message-ID: <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com>

So when I run "LD_DEBUG=all /opt/csw/sbin/amstatus test" this reference to
/opt/csw/lib/sparcv9/libgthread-2.0.so.0 is only mentioned once in the
output, see below. I'm not sure out to interrupt this output, does it mean
the libgthread-2.0.so.0 is trying to use the 64bit library?

22836: 1: find object=libgthread-2.0.so.0; searching
22836: 1:  search path=/opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib 
(RPATH from file /opt/csw/lib/libgobject-2.0.so.0)
22836: 1:  trying path=/opt/csw/lib/sparcv9+vis2/libgthread-2.0.so.0
22836: 1:  trying path=/opt/csw/lib/sparcv9+vis/libgthread-2.0.so.0
22836: 1:  trying path=/opt/csw/lib/sparcv9/libgthread-2.0.so.0
22836: 1:
22836: 1: file=/opt/csw/lib/sparcv9/libgthread-2.0.so.0;  rejected: wrong
ELF class: ELFCLASS64
22836: 1:
22836: 1:  trying path=/opt/csw/lib/sparcv8plus+vis2/libgthread-2.0.so.0
22836: 1:  trying path=/opt/csw/lib/sparcv8plus+vis/libgthread-2.0.so.0
22836: 1:  trying path=/opt/csw/lib/sparcv8plus/libgthread-2.0.so.0
22836: 1:  trying path=/opt/csw/lib/sparcv8/libgthread-2.0.so.0
22836: 1: file=/opt/csw/lib/sparcv8/libgthread-2.0.so.0  skipped: already
processed as /opt/csw/lib/libgthread-2.0.so.0
22836: 1:
22836: 1: file=/opt/csw/lib/libgobject-2.0.so.0;  add binding to:
22836: 1:     file=/opt/csw/lib/libgthread-2.0.so.0   [ NEEDED ]

> On Fri, Apr 23, 2010 at 12:50 PM, Darin Perusich
> <Darin.Perusich at cognigencorp.com> wrote:
>> Hello,
>>
>> I'm testing a new Amanda package and all the apps are core dumping and
>> for some reason they are opening both the 32 and 64bit
>> libgthread-2.0.so.0 libraries. Has anyone ever seen this or have any
>> idea why it might be happening?
>
> I believe that
>
> LD_DEBUG=files /run/your/app
>
>


From phil at bolthole.com  Sat Apr 24 07:01:53 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 23 Apr 2010 22:01:53 -0700
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
In-Reply-To: <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com>
References: <4BD1FA08.2090106@cognigencorp.com>
	<j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>
	<43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com>
Message-ID: <u2vd57eab941004232201wa837d456tea3219aec87c40d9@mail.gmail.com>

On Friday, April 23, 2010,  <Darin.Perusich at cognigencorp.com> wrote:
> So when I run "LD_DEBUG=all /opt/csw/sbin/amstatus test" this reference to
> /opt/csw/lib/sparcv9/libgthread-2.0.so.0 is only mentioned once in the
> output, see below. I'm not sure out to interrupt this output, does it mean
> the libgthread-2.0.so.0 is trying to use the 64bit library?
>


it would appear that it CONSIDERS using it... for which it has to
open() the file... but then appropriately rejects it.

the odd thing is why ISALIST is expanding to include sparc v9 for a 32
bit executable. something very wrong there.
perhaps a prior library incorrectly loaded ?

From maciej at opencsw.org  Sat Apr 24 09:49:14 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sat, 24 Apr 2010 08:49:14 +0100
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs idle, python,
	python_devel, python_tk
In-Reply-To: <u2pd57eab941004231349rae38fbdbz94e37a3701f2d0cb@mail.gmail.com>
References: <201004200557.o3K5vQGr024663@login.bo.opencsw.org> 
	<u2pd57eab941004231349rae38fbdbz94e37a3701f2d0cb@mail.gmail.com>
Message-ID: <l2yce97543b1004240049tb900327fh30cececd7f1bfe0b@mail.gmail.com>

No dia 23 de Abril de 2010 21:49, Philip Brown <phil at bolthole.com> escreveu:
> erm... there's some really really old legacy garbage in the python package.
>
> ERROR: build-machine paths found in file
> python-2.6.5,REV=2010.04.19-SunOS5.9-sparc-CSW.pkg.gz

Yes, this is known and expected.  It deserves a bit of explanation.
I'm cc'ing maintainers@, as the same issue might affect other people
too.

The CSWpython package contains legacy shared library, namely
/opt/csw/lib/libpython2.5.so.1.0.  This file is stored in the
repository in the binary form and added to the pkgroot in a separate
step during building.  It's not recompiled any more.  There's no
description to compile it, so it's bound to stay the way it is until
it's removed.

The legacy library contains build-machine paths, and it always did.
Here's a session dump from build9s:

maciej at current9s :~/src/opencsw/pkg/python/trunk > ggrep medusa
/opt/csw/lib/libpython2.5.so.1.0
Binary file /opt/csw/lib/libpython2.5.so.1.0 matches

The reason we didn't know about it is because the pre-maciej version
of checkpkg failed to detect that.  Current version of checkpkg does
detect and report it.  There is a need to tell checkpkg that we know
about this problem and that it's okay.  If you look into
python-2.6.5,REV=2010.04.19-SunOS5.9-sparc-CSW.pkg.gz, you'll notice:

/opt/csw/share/checkpkg/overrides/python

containing:

CSWpython: file-with-bad-content /export/medusa
root/opt/csw/lib/libpython2.5.so.1.0
CSWpython: file-with-bad-content /opt/build root/opt/csw/lib/libpython2.5.so.1.0
CSWpython: file-with-bad-content /export/medusa
root/opt/csw/share/checkpkg/overrides/python
CSWpython: file-with-bad-content /opt/build
root/opt/csw/share/checkpkg/overrides/python

The override file is a plaintext file, and it contains the
"/export/medusa" string.  I believe that this is the file that the old
checkpkg complained about.  If it was able to detect build-machine
paths reliably, it would have always complained about CSWpython.

Looking at the whole catalog, there are currently 189 packages
affected by this issue (build-machine paths).  Here's the list of
packages with details: http://www.opencsw.org/~maciej/bad-content.txt

Maciej

From rupert at opencsw.org  Sun Apr 25 17:05:49 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 25 Apr 2010 17:05:49 +0200
Subject: [csw-maintainers] getting apache2 ldaps authentication to work:
	test openldap, apache2
In-Reply-To: <h2n6af4271004250803vf58386c0m3aab405ef3fe5470@mail.gmail.com>
References: <h2n6af4271004250803vf58386c0m3aab405ef3fe5470@mail.gmail.com>
Message-ID: <l2k6af4271004250805pd1a24197v84ad7c149eabadad@mail.gmail.com>

hi,

last week we did not get the ldaps authentication of apache2 working
with the current package versions in http://opencsw.org/packages. up
to now we have no idea if openssl might be responsible or openldap, or
even apache2.

so i tried to upgrade to recent and recompile the concerned packages
apche2 (done), openssl (failed in at configure), and openldap
(half-done).

as there are so many dependencies i'd be glad about some help and
testing. we will test only the following scenario: apache2
authentication via ldaps, on sparc. as openssl recently was
successfully built, we will ?try two scenarios, (1) with the old
openssl and (2) with a newly built openldap.

when compiling i had 3 issues see below for the longer error messages:
1. openldap did not link on i386
2. gar complained when doing a remerge
3. openssl - configure did not work


ad 1.
/usr/ccs/bin/ld -G -h libldap-2.3.so.0 -o .libs/libldap-2.3.so.0.2.31
.libs/bind.o .libs/open.o .libs/result.o .libs/error.o .libs/compare.o
.libs/search.o .libs/controls.o .libs/messages.o .libs/references.o
.libs/extended.o .libs/cyrus.o .libs/modify.o .libs/add.o
.libs/modrdn.o .libs/delete.o .libs/abandon.o .libs/sasl.o
.libs/sbind.o .libs/kbind.o .libs/unbind.o .libs/cancel.o
.libs/filter.o .libs/free.o .libs/sort.o .libs/passwd.o .libs/whoami.o
.libs/getdn.o .libs/getentry.o .libs/getattr.o .libs/getvalues.o
.libs/addentry.o .libs/request.o .libs/os-ip.o .libs/url.o
.libs/sortctrl.o .libs/vlvctrl.o .libs/init.o .libs/options.o
.libs/print.o .libs/string.o .libs/util-int.o .libs/schema.o
.libs/charray.o .libs/tls.o .libs/os-local.o .libs/dnssrv.o
.libs/utf-8.o .libs/utf-8-conv.o .libs/turn.o .libs/groupings.o
.libs/txn.o .libs/ppolicy.o .libs/version.o ?-R/opt/csw/lib/64
-L/opt/csw/bdb44/lib/64 -L/opt/csw/lib/64
-L/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/install-isa-amd64-garversion-2.3.43/opt/csw/lib/64
-llber -lresolv -lgen -lnsl -lsocket -lssl -lcrypto -lc
ld: fatal: file libld.so.3: dlopen failed: ld.so.1: ld: fatal:
libld.so.3: open failed: No such file or directory
libtool: install: error: relink `libldap.la' with the above command
before installing it
gmake[4]: *** [install-local] Error 1
gmake[4]: Leaving directory
`/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/build-isa-amd64-garversion-2.3.43/openldap-2.3.43/libraries/libldap'
gmake[3]: *** [install-common] Error 1
gmake[3]: Leaving directory
`/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/build-isa-amd64-garversion-2.3.43/openldap-2.3.43/libraries'
gmake[2]: *** [install-common] Error 1
gmake[2]: Leaving directory
`/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/build-isa-amd64-garversion-2.3.43/openldap-2.3.43'
gmake[1]: *** [install-work/solaris9-i386/build-isa-amd64-garversion-2.3.43/openldap-2.3.43/Makefile]
Error 2
gmake[1]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk'
gmake: *** [reset-install-isa-amd64-garversion-2.3.43] Error 2
gmake: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk'
Connection to current9x closed.


ad 2.
just as a sidenote, is it possible that there is still a glitch in
gar? in the beginning, the openldap compile ended with a compiled
sparc 2.4.21 version, with checkpkg failing. correcting the makefile
and doing a repackage ended with The ISA 'amd64' can not be build on
this kernel with the arch 'i386' :

rupert at current9s ~/mgar/pkg/openldap/trunk
$ gmake platforms-reinstall platforms-remerge platforms-repackage
....

/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/pkgroot/./etc/opt/csw/openldap/DB_CONFIG.example
/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/pkgroot/./etc/opt/csw/openldap/ldap.conf
/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/pkgroot/./etc/opt/csw/openldap/slapd.conf.default
gmake[1]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk'
gmake[1]: Entering directory `/home/rupert/mgar/pkg/openldap/trunk'
[ Reset install state for modulation isa-amd64-garversion-2.3.43:
ISA=amd64 GARVERSION=2.3.43 ]
gmake[1]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk'
gmake[1]: Entering directory `/home/rupert/mgar/pkg/openldap/trunk'
gar/gar.conf.mk:418: *** The ISA 'amd64' can not be build on this
kernel with the arch 'i386'. ?Stop.
gmake[1]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk'
gmake: *** [reset-install-isa-amd64-garversion-2.3.43] Error 2
gmake: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk'
Connection to current9x closed.
gmake: *** [platforms-reinstall] Error 2
rupert at current9s ~/mgar/pkg/openldap/trunk


rupert.

From dam at opencsw.org  Sun Apr 25 21:41:11 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 25 Apr 2010 21:41:11 +0200
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
In-Reply-To: <u2vd57eab941004232201wa837d456tea3219aec87c40d9@mail.gmail.com>
References: <4BD1FA08.2090106@cognigencorp.com>
	<j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>
	<43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com>
	<u2vd57eab941004232201wa837d456tea3219aec87c40d9@mail.gmail.com>
Message-ID: <81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org>

Hi,

Am 24.04.2010 um 07:01 schrieb Philip Brown:
> On Friday, April 23, 2010,  <Darin.Perusich at cognigencorp.com> wrote:
>> So when I run "LD_DEBUG=all /opt/csw/sbin/amstatus test" this reference to
>> /opt/csw/lib/sparcv9/libgthread-2.0.so.0 is only mentioned once in the
>> output, see below. I'm not sure out to interrupt this output, does it mean
>> the libgthread-2.0.so.0 is trying to use the 64bit library?
> 
> it would appear that it CONSIDERS using it... for which it has to
> open() the file... but then appropriately rejects it.
> 
> the odd thing is why ISALIST is expanding to include sparc v9 for a 32
> bit executable. something very wrong there.
> perhaps a prior library incorrectly loaded ?

This is perfectly normal. The reason is because sysinfo(2)(SI_ISALIST,...)
doesn't look for 32/64 bits for the result - it is always the same. The
reason for this is because /usr/lib/isaexec uses this same syscall to
find the best ISA, which may very well be 64 bit binary even if isaesec
itself is 32 bit. It may be wise of there would be another syscall for
the linker, but there isn't. Hence this is normal behaviour and does
not lead to your problem. There must be another cause.


Best regards

  -- Dago

From dam at opencsw.org  Sun Apr 25 21:56:52 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 25 Apr 2010 21:56:52 +0200
Subject: [csw-maintainers] getting apache2 ldaps authentication to work:
	test openldap, apache2
In-Reply-To: <l2k6af4271004250805pd1a24197v84ad7c149eabadad@mail.gmail.com>
References: <h2n6af4271004250803vf58386c0m3aab405ef3fe5470@mail.gmail.com>
	<l2k6af4271004250805pd1a24197v84ad7c149eabadad@mail.gmail.com>
Message-ID: <B45C888E-E153-41D0-9B20-75AEEDB576FD@opencsw.org>

Hi Rupert.

Am 25.04.2010 um 17:05 schrieb rupert THURNER:
> last week we did not get the ldaps authentication of apache2 working
> with the current package versions in http://opencsw.org/packages. up
> to now we have no idea if openssl might be responsible or openldap, or
> even apache2.
> 
> so i tried to upgrade to recent and recompile the concerned packages
> apche2 (done), openssl (failed in at configure),

Yann: Does it build cleanly for you?

> and openldap
> (half-done).

The package is AFAIK not ready for release and needs some more work.
David Mantock was working on it. David, what is your current status
about it?
I'll also have a look, but the more eyes the better.

> as there are so many dependencies i'd be glad about some help and
> testing. we will test only the following scenario: apache2
> authentication via ldaps, on sparc. as openssl recently was
> successfully built, we will  try two scenarios, (1) with the old
> openssl and (2) with a newly built openldap.
> 
> when compiling i had 3 issues see below for the longer error messages:
> 1. openldap did not link on i386
> 2. gar complained when doing a remerge

I'll see if I can reproduce it.

> 3. openssl - configure did not work

It looks like the patches can not be applied to 1.0.0 Yann?


Best regards

  -- Dago

From ihsan at opencsw.org  Sun Apr 25 22:04:46 2010
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Sun, 25 Apr 2010 22:04:46 +0200
Subject: [csw-maintainers] Apache 2 Package
In-Reply-To: <u2q6af4271004190922p40994628r576f5b1483b3b9d4@mail.gmail.com>
References: <4ADB45B0.1000207@opencsw.org> <4BCACCDE.7060807@opencsw.org>
	<o2q625385e31004181205s26f2759au4b02eb2b28c0dabf@mail.gmail.com>
	<4BCC24BE.1080900@opencsw.org>
	<u2q6af4271004190922p40994628r576f5b1483b3b9d4@mail.gmail.com>
Message-ID: <4BD4A05E.4080409@opencsw.org>

On 4/19/10 6:22 PM, rupert THURNER wrote:

>>>>> The Apache 2 package needs to be reworked and I can't find any
>>>>> additional ressources at this time. Would be great if someone could take
>>>>> over this package.
>>>> Still nobody interested in taking over Apache?
>>> Didn't Rupert do some work on it?
>> Not that I'm aware of.
>> Rupert?
> 
> maciej, and me did some yes .. but this was far from good. now there
> is only one single package contrary to the sophisticated setup before.
> a package of version 2.2.14 is on
> http://mirror.opencsw.org/testing.html.

Would be great if you guys could go on with with the work. As I already
mentioned before, I really don't have the resources to rework the package.



Ihsan

-- 
ihsan at dogan.ch		http://blog.dogan.ch/

From yann at pleiades.fr.eu.org  Mon Apr 26 13:18:25 2010
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 26 Apr 2010 13:18:25 +0200
Subject: [csw-maintainers] getting apache2 ldaps authentication to work:
 test openldap, apache2
In-Reply-To: <B45C888E-E153-41D0-9B20-75AEEDB576FD@opencsw.org>
References: <h2n6af4271004250803vf58386c0m3aab405ef3fe5470@mail.gmail.com>
	<l2k6af4271004250805pd1a24197v84ad7c149eabadad@mail.gmail.com>
	<B45C888E-E153-41D0-9B20-75AEEDB576FD@opencsw.org>
Message-ID: <4BD57681.1020007@pleiades.fr.eu.org>

Le 25/04/2010 21:56, Dagobert Michelsen a ?crit :
>> so i tried to upgrade to recent and recompile the concerned packages
>> apche2 (done), openssl (failed in at configure),
>
> Yann: Does it build cleanly for you?

Are we talking about 0.9.8 or 1.0.0 ?


>> 3. openssl - configure did not work
>
> It looks like the patches can not be applied to 1.0.0 Yann?

Yes it can't. I already locally updated the patches in the openssl1 
package but didn't commit until now.
You can find the updated patch here:
http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/more_configure_targets.patch?revision=9769&view=raw

But I didn't finish working on this package, so I am not sure it will 
build and work cleanly.

Yann

From Darin.Perusich at cognigencorp.com  Mon Apr 26 15:09:49 2010
From: Darin.Perusich at cognigencorp.com (Darin Perusich)
Date: Mon, 26 Apr 2010 09:09:49 -0400
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
In-Reply-To: <81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org>
References: <4BD1FA08.2090106@cognigencorp.com>	<j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>	<43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com>	<u2vd57eab941004232201wa837d456tea3219aec87c40d9@mail.gmail.com>
	<81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org>
Message-ID: <4BD5909D.6080207@cognigencorp.com>

Dago,

On 04/25/2010 03:41 PM, Dagobert Michelsen wrote:
> Hi,
> 
> Am 24.04.2010 um 07:01 schrieb Philip Brown:
>> On Friday, April 23, 2010,  <Darin.Perusich at cognigencorp.com> wrote:
>>> So when I run "LD_DEBUG=all /opt/csw/sbin/amstatus test" this reference to
>>> /opt/csw/lib/sparcv9/libgthread-2.0.so.0 is only mentioned once in the
>>> output, see below. I'm not sure out to interrupt this output, does it mean
>>> the libgthread-2.0.so.0 is trying to use the 64bit library?
>>
>> it would appear that it CONSIDERS using it... for which it has to
>> open() the file... but then appropriately rejects it.
>>
>> the odd thing is why ISALIST is expanding to include sparc v9 for a 32
>> bit executable. something very wrong there.
>> perhaps a prior library incorrectly loaded ?
> 
> This is perfectly normal. The reason is because sysinfo(2)(SI_ISALIST,...)
> doesn't look for 32/64 bits for the result - it is always the same. The
> reason for this is because /usr/lib/isaexec uses this same syscall to
> find the best ISA, which may very well be 64 bit binary even if isaesec
> itself is 32 bit. It may be wise of there would be another syscall for
> the linker, but there isn't. Hence this is normal behaviour and does
> not lead to your problem. There must be another cause.
> 

You say this is normal behavior, i.e listing all the applicable
libraries, but there is no other instance where an open() to a 64bit
library is occurring. Whenever a 64bit lib is evaluated I get "rejected:
wrong ELF class: ELFCLASS64" for those libs.

-- 
Darin Perusich
Unix Systems Administrator
Cognigen Corporation
395 Youngs Rd.
Williamsville, NY 14221
Phone: 716-633-3463
Email: darinper at cognigencorp.com

From dam at opencsw.org  Mon Apr 26 17:10:48 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 26 Apr 2010 17:10:48 +0200
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
In-Reply-To: <4BD5909D.6080207@cognigencorp.com>
References: <4BD1FA08.2090106@cognigencorp.com>	<j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>	<43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com>	<u2vd57eab941004232201wa837d456tea3219aec87c40d9@mail.gmail.com>
	<81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org>
	<4BD5909D.6080207@cognigencorp.com>
Message-ID: <CEDC1586-595A-43F6-B5C0-8BDB074F3A06@opencsw.org>

Hi Darin,

Am 26.04.2010 um 15:09 schrieb Darin Perusich:
> You say this is normal behavior, i.e listing all the applicable
> libraries, but there is no other instance where an open() to a 64bit
> library is occurring. Whenever a 64bit lib is evaluated I get  
> "rejected:
> wrong ELF class: ELFCLASS64" for those libs.

Just take an arbitrary binary from /opt/csw/bin which has $ISALIST
in the RPATH, like 411toppm. It is always the same behaviour:

dam at testing9s :/opt/csw/bin > dump -Lv 411toppm

411toppm:

   **** DYNAMIC SECTION INFORMATION ****
.dynamic:
[INDEX] Tag         Value
[1]     NEEDED          libnetpbm.so.10
[2]     NEEDED          libpng12.so.0
[3]     NEEDED          libz.so
[4]     NEEDED          libjpeg.so.62
[5]     NEEDED          libtiff.so.3
[6]     NEEDED          libm.so.1
[7]     NEEDED          libsocket.so.1
[8]     NEEDED          libnsl.so.1
[9]     NEEDED          libc.so.1
[10]    INIT            0x1fe258
[11]    FINI            0x1fe268
[12]    RUNPATH         /opt/csw/lib/$ISALIST:/opt/csw/lib
[13]    RPATH           /opt/csw/lib/$ISALIST:/opt/csw/lib
[14]    HASH            0x100e8
...

dam at testing9s :/opt/csw/bin > truss -f ./411toppm
2932:   execve("netpbm", 0xFFBFFAD4, 0xFFBFFADC)  argc = 1
...
2932:   mprotect(0xFF1C0000, 159436, PROT_READ|PROT_EXEC) = 0
2932:   stat("/opt/csw/lib/sparcv9+vis2/libjpeg.so.7", 0xFFBFF148)  
Err#2 ENOENT
2932:   stat("/opt/csw/lib/sparcv9+vis/libjpeg.so.7", 0xFFBFF148)  
Err#2 ENOENT
2932:   stat("/opt/csw/lib/sparcv9/libjpeg.so.7", 0xFFBFF148) = 0
2932:   resolvepath("/opt/csw/lib/sparcv9/libjpeg.so.7", "/opt/csw/lib/ 
sparcv9/libjpeg.so.7.0.0", 1023) = 37
2932:   open("/opt/csw/lib/sparcv9/libjpeg.so.7", O_RDONLY) = 3
2932:   mmap(0x00010000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE| 
MAP_ALIGN, 3, 0) = 0xFF0F0000
2932:   close(3)                                        = 0
2932:   stat("/opt/csw/lib/sparcv8plus+vis2/libjpeg.so.7", 0xFFBFF148)  
Err#2 ENOENT
2932:   stat("/opt/csw/lib/sparcv8plus+vis/libjpeg.so.7", 0xFFBFF148)  
Err#2 ENOENT
2932:   stat("/opt/csw/lib/sparcv8plus/libjpeg.so.7", 0xFFBFF148)  
Err#2 ENOENT
2932:   stat("/opt/csw/lib/sparcv8/libjpeg.so.7", 0xFFBFF148) = 0
2932:   resolvepath("/opt/csw/lib/sparcv8/libjpeg.so.7", "/opt/csw/lib/ 
libjpeg.so.7.0.0", 1023) = 29
2932:   open("/opt/csw/lib/sparcv8/libjpeg.so.7", O_RDONLY) = 3
2932:   mmap(0xFF0F0000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE| 
MAP_FIXED, 3, 0) = 0xFF0F0000
2932:   mmap(0x00010000, 368640, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE| 
MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDA0000
...


Best regards

   -- Dago

From Darin.Perusich at cognigencorp.com  Mon Apr 26 18:26:14 2010
From: Darin.Perusich at cognigencorp.com (Darin Perusich)
Date: Mon, 26 Apr 2010 12:26:14 -0400
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
In-Reply-To: <CEDC1586-595A-43F6-B5C0-8BDB074F3A06@opencsw.org>
References: <4BD1FA08.2090106@cognigencorp.com>	<j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>	<43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com>	<u2vd57eab941004232201wa837d456tea3219aec87c40d9@mail.gmail.com>	<81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org>	<4BD5909D.6080207@cognigencorp.com>
	<CEDC1586-595A-43F6-B5C0-8BDB074F3A06@opencsw.org>
Message-ID: <4BD5BEA6.9070800@cognigencorp.com>

Hi Dago,

I see what you're saying but the behavior I'm seeing is that it's only
attempting to open the 64bit lib and never the 32bit one, see below.
I've been in contact with the Amanda developers and they're not sure
what's going on or how to proceed. From how things appear the problem is
outside of the amanda libs and is glib2 related.

I've definitely reached a point where I don't know how to proceed so any
guidance will be greatly appreciated.

Thanks

<testing9s:~>  grep open /tmp/amtruss.out |grep -v NOENT | grep gthread
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5
open("/opt/csw/lib/sparcv8/libgthread-2.0.so.0", O_RDONLY) = 5
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 4
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5
open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5


On 04/26/2010 11:10 AM, Dagobert Michelsen wrote:
> Hi Darin,
> 
> Am 26.04.2010 um 15:09 schrieb Darin Perusich:
>> You say this is normal behavior, i.e listing all the applicable
>> libraries, but there is no other instance where an open() to a 64bit
>> library is occurring. Whenever a 64bit lib is evaluated I get "rejected:
>> wrong ELF class: ELFCLASS64" for those libs.
> 
> Just take an arbitrary binary from /opt/csw/bin which has $ISALIST
> in the RPATH, like 411toppm. It is always the same behaviour:
> 
> dam at testing9s :/opt/csw/bin > dump -Lv 411toppm
> 
> 411toppm:
> 
>   **** DYNAMIC SECTION INFORMATION ****
> .dynamic:
> [INDEX] Tag         Value
> [1]     NEEDED          libnetpbm.so.10
> [2]     NEEDED          libpng12.so.0
> [3]     NEEDED          libz.so
> [4]     NEEDED          libjpeg.so.62
> [5]     NEEDED          libtiff.so.3
> [6]     NEEDED          libm.so.1
> [7]     NEEDED          libsocket.so.1
> [8]     NEEDED          libnsl.so.1
> [9]     NEEDED          libc.so.1
> [10]    INIT            0x1fe258
> [11]    FINI            0x1fe268
> [12]    RUNPATH         /opt/csw/lib/$ISALIST:/opt/csw/lib
> [13]    RPATH           /opt/csw/lib/$ISALIST:/opt/csw/lib
> [14]    HASH            0x100e8
> ...
> 
> dam at testing9s :/opt/csw/bin > truss -f ./411toppm
> 2932:   execve("netpbm", 0xFFBFFAD4, 0xFFBFFADC)  argc = 1
> ...
> 2932:   mprotect(0xFF1C0000, 159436, PROT_READ|PROT_EXEC) = 0
> 2932:   stat("/opt/csw/lib/sparcv9+vis2/libjpeg.so.7", 0xFFBFF148) Err#2
> ENOENT
> 2932:   stat("/opt/csw/lib/sparcv9+vis/libjpeg.so.7", 0xFFBFF148) Err#2
> ENOENT
> 2932:   stat("/opt/csw/lib/sparcv9/libjpeg.so.7", 0xFFBFF148) = 0
> 2932:   resolvepath("/opt/csw/lib/sparcv9/libjpeg.so.7",
> "/opt/csw/lib/sparcv9/libjpeg.so.7.0.0", 1023) = 37
> 2932:   open("/opt/csw/lib/sparcv9/libjpeg.so.7", O_RDONLY) = 3
> 2932:   mmap(0x00010000, 32768, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_ALIGN, 3, 0) = 0xFF0F0000
> 2932:   close(3)                                        = 0
> 2932:   stat("/opt/csw/lib/sparcv8plus+vis2/libjpeg.so.7", 0xFFBFF148)
> Err#2 ENOENT
> 2932:   stat("/opt/csw/lib/sparcv8plus+vis/libjpeg.so.7", 0xFFBFF148)
> Err#2 ENOENT
> 2932:   stat("/opt/csw/lib/sparcv8plus/libjpeg.so.7", 0xFFBFF148) Err#2
> ENOENT
> 2932:   stat("/opt/csw/lib/sparcv8/libjpeg.so.7", 0xFFBFF148) = 0
> 2932:   resolvepath("/opt/csw/lib/sparcv8/libjpeg.so.7",
> "/opt/csw/lib/libjpeg.so.7.0.0", 1023) = 29
> 2932:   open("/opt/csw/lib/sparcv8/libjpeg.so.7", O_RDONLY) = 3
> 2932:   mmap(0xFF0F0000, 32768, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF0F0000
> 2932:   mmap(0x00010000, 368640, PROT_NONE,
> MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDA0000
> ...
> 
> 
> Best regards
> 
>   -- Dago
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.

-- 
Darin Perusich
Unix Systems Administrator
Cognigen Corporation
395 Youngs Rd.
Williamsville, NY 14221
Phone: 716-633-3463
Email: darinper at cognigencorp.com

From phil at bolthole.com  Mon Apr 26 18:31:09 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 26 Apr 2010 09:31:09 -0700
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
In-Reply-To: <4BD5BEA6.9070800@cognigencorp.com>
References: <4BD1FA08.2090106@cognigencorp.com>
	<j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>
	<43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com>
	<u2vd57eab941004232201wa837d456tea3219aec87c40d9@mail.gmail.com>
	<81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org>
	<4BD5909D.6080207@cognigencorp.com>
	<CEDC1586-595A-43F6-B5C0-8BDB074F3A06@opencsw.org>
	<4BD5BEA6.9070800@cognigencorp.com>
Message-ID: <z2td57eab941004260931p9cefe960p5f80d39805be633d@mail.gmail.com>

On Mon, Apr 26, 2010 at 9:26 AM, Darin Perusich
<Darin.Perusich at cognigencorp.com> wrote:
> Hi Dago,
>
> I see what you're saying but the behavior I'm seeing is that it's only
> attempting to open the 64bit lib and never the 32bit one, see below.

Odd.I thought I saw the attempt to open the other one, in the LD_DEBUG
output, rather than the truss one.

From phil at bolthole.com  Mon Apr 26 20:02:15 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 26 Apr 2010 11:02:15 -0700
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs idle, python,
	python_devel, python_tk
In-Reply-To: <l2yce97543b1004240049tb900327fh30cececd7f1bfe0b@mail.gmail.com>
References: <201004200557.o3K5vQGr024663@login.bo.opencsw.org>
	<u2pd57eab941004231349rae38fbdbz94e37a3701f2d0cb@mail.gmail.com>
	<l2yce97543b1004240049tb900327fh30cececd7f1bfe0b@mail.gmail.com>
Message-ID: <y2md57eab941004261102la37affd6teb5342df84d03399@mail.gmail.com>

thanks for the explaination.
batched

From david.mantock at gmx.ch  Mon Apr 26 17:32:28 2010
From: david.mantock at gmx.ch (David Mantock)
Date: Mon, 26 Apr 2010 17:32:28 +0200
Subject: [csw-maintainers] getting apache2 ldaps authentication to work:
	test openldap, apache2
In-Reply-To: <B45C888E-E153-41D0-9B20-75AEEDB576FD@opencsw.org>
References: <h2n6af4271004250803vf58386c0m3aab405ef3fe5470@mail.gmail.com>
	<l2k6af4271004250805pd1a24197v84ad7c149eabadad@mail.gmail.com>
	<B45C888E-E153-41D0-9B20-75AEEDB576FD@opencsw.org>
Message-ID: <059EA4012F9540BA9CCD68FFD5CD6556@DavidPC>

I am sorry, but I do not have any time to be a CSW maintainer.

I had hoped it would be OK, but my personal circumstances do not allow for 
it.

Best regards,
David Mantock

--------------------------------------------------
From: "Dagobert Michelsen" <dam at opencsw.org>
Sent: Sunday, April 25, 2010 9:56 PM
To: "List for OpenCSW maintainers" <maintainers at lists.opencsw.org>
Cc: "Yann Rouillard" <yann at pleiades.fr.eu.org>; "David Mantock" 
<david.mantock at gmx.ch>
Subject: Re: [csw-maintainers] getting apache2 ldaps authentication to work: 
test openldap, apache2

> Hi Rupert.
>
> Am 25.04.2010 um 17:05 schrieb rupert THURNER:
>> last week we did not get the ldaps authentication of apache2 working
>> with the current package versions in http://opencsw.org/packages. up
>> to now we have no idea if openssl might be responsible or openldap, or
>> even apache2.
>>
>> so i tried to upgrade to recent and recompile the concerned packages
>> apche2 (done), openssl (failed in at configure),
>
> Yann: Does it build cleanly for you?
>
>> and openldap
>> (half-done).
>
> The package is AFAIK not ready for release and needs some more work.
> David Mantock was working on it. David, what is your current status
> about it?
> I'll also have a look, but the more eyes the better.
>
>> as there are so many dependencies i'd be glad about some help and
>> testing. we will test only the following scenario: apache2
>> authentication via ldaps, on sparc. as openssl recently was
>> successfully built, we will  try two scenarios, (1) with the old
>> openssl and (2) with a newly built openldap.
>>
>> when compiling i had 3 issues see below for the longer error messages:
>> 1. openldap did not link on i386
>> 2. gar complained when doing a remerge
>
> I'll see if I can reproduce it.
>
>> 3. openssl - configure did not work
>
> It looks like the patches can not be applied to 1.0.0 Yann?
>
>
> Best regards
>
>  -- Dago 


From maciej at opencsw.org  Tue Apr 27 19:55:26 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 27 Apr 2010 18:55:26 +0100
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs py_hachoir_core,
	py_hachoir_parser
In-Reply-To: <u2qd57eab941004270931o6cfce7ecrd55a277812f024cd@mail.gmail.com>
References: <201004270624.o3R6OnMw010611@login.bo.opencsw.org> 
	<u2qd57eab941004270931o6cfce7ecrd55a277812f024cd@mail.gmail.com>
Message-ID: <w2gce97543b1004271055q24504ca9v1e11f86bbb3e39c3@mail.gmail.com>

No dia 27 de Abril de 2010 17:31, Philip Brown <phil at bolthole.com> escreveu:
> huh.
> it would appear that the "core" was already named normally, but the
> parser was not.
> even though the "software name" already had the py prefix.

Yes, it has fallen through the cracks.  I had the right thing in mind,
but missed the pkgname.

I'm planning on adding a check for it.

Dear maintainers, what do you think about the following:

If a package installs stuff into /opt/csw/lib/python/site-packages,
checkpkg will require the pkgname to begin with CSWpy-" and
catalogname with "py_".  If there are larger packages with just a
couple Python files, a Python subpackage might be separated out (which
usually is a good practice anyway) and prefixed.  If there are
exceptions (such as pythonsvn), overrides can be used.

Thoughts?

Maciej

From skayser at opencsw.org  Wed Apr 28 00:32:31 2010
From: skayser at opencsw.org (Sebastian Kayser)
Date: Wed, 28 Apr 2010 00:32:31 +0200
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs py_hachoir_core,
 py_hachoir_parser
In-Reply-To: <w2gce97543b1004271055q24504ca9v1e11f86bbb3e39c3@mail.gmail.com>
References: <201004270624.o3R6OnMw010611@login.bo.opencsw.org>
	<u2qd57eab941004270931o6cfce7ecrd55a277812f024cd@mail.gmail.com>
	<w2gce97543b1004271055q24504ca9v1e11f86bbb3e39c3@mail.gmail.com>
Message-ID: <4BD765FF.3080704@opencsw.org>

Maciej (Matchek) Blizinski wrote on 27.04.2010 19:55:
> No dia 27 de Abril de 2010 17:31, Philip Brown <phil at bolthole.com> escreveu:
>> huh.
>> it would appear that the "core" was already named normally, but the
>> parser was not.
>> even though the "software name" already had the py prefix.
> 
> Yes, it has fallen through the cracks.  I had the right thing in mind,
> but missed the pkgname.
> 
> I'm planning on adding a check for it.
> 
> Dear maintainers, what do you think about the following:
> 
> If a package installs stuff into /opt/csw/lib/python/site-packages,
> checkpkg will require the pkgname to begin with CSWpy-" and
> catalogname with "py_".  If there are larger packages with just a
> couple Python files, a Python subpackage might be separated out (which
> usually is a good practice anyway) and prefixed.  If there are
> exceptions (such as pythonsvn), overrides can be used.
> 
> Thoughts?

Sounds good. Helps to embed standards into the packaging workflow itself
rather than to rely on people being aware of every tiny detail (yeah I
know, they should be aware about the py_ prefix, but well).

Does checkpkg already support explanations for thrown errors so that
people can get a descriptive error message?

Sebastian

From james at opencsw.org  Wed Apr 28 10:12:17 2010
From: james at opencsw.org (James Lee)
Date: Wed, 28 Apr 2010 08:12:17 GMT
Subject: [csw-maintainers] newpkgs py_hachoir_core, py_hachoir_parser
In-Reply-To: <w2gce97543b1004271055q24504ca9v1e11f86bbb3e39c3@mail.gmail.com>
References: <w2gce97543b1004271055q24504ca9v1e11f86bbb3e39c3@mail.gmail.com>
Message-ID: <20100428.8121700.97698744@gyor.oxdrove.co.uk>

On 27/04/10, 18:55:26, Maciej "(Matchek)" Blizinski <maciej at opencsw.org> 
wrote regarding Re: [csw-maintainers] [csw-pkgsubmissions] newpkgs 
py_hachoir_core, py_hachoir_parser:

> If a package installs stuff into /opt/csw/lib/python/site-packages,
> checkpkg will require the pkgname to begin with CSWpy-" and
> catalogname with "py_".

No.

The fetchmailconf package contains a program called fetchmailconf that
just happens to use python, a fact between uninteresting and irrelevant
to the user.

You could mean if a package exclusively installs stuff into.

Avoidance tactic: I put fetchmailconf's python files in another 
directory.



James.

From maciej at opencsw.org  Wed Apr 28 14:54:29 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 28 Apr 2010 13:54:29 +0100
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs py_hachoir_core,
	py_hachoir_parser
In-Reply-To: <4BD765FF.3080704@opencsw.org>
References: <201004270624.o3R6OnMw010611@login.bo.opencsw.org> 
	<u2qd57eab941004270931o6cfce7ecrd55a277812f024cd@mail.gmail.com> 
	<w2gce97543b1004271055q24504ca9v1e11f86bbb3e39c3@mail.gmail.com> 
	<4BD765FF.3080704@opencsw.org>
Message-ID: <j2tce97543b1004280554m5a1236c3q8db9b2a437ff789f@mail.gmail.com>

No dia 27 de Abril de 2010 23:32, Sebastian Kayser
<skayser at opencsw.org> escreveu:
> Sounds good. Helps to embed standards into the packaging workflow itself

Yes, this is the idea.  I've committed the new check, plus unit tests.

> Does checkpkg already support explanations for thrown errors so that
> people can get a descriptive error message?

Yes, there is a Messenger class, which is passed to every checking
function.  It has a Message(str) function, to which you can pass a
message string.  You don't have to worry about the line breaks, the
text will be automatically reformatted later on.  You can pass it one
long string with no line breaks and it will look nice in the output.
Here's an example:

-----------------8<--------------------
CSWhachoir-parser:
# The package installs files into /opt/csw/lib/python. For example,
# '/opt/csw/lib/python/site-packages'. However, the pkgname doesn't start with
# 'CSWpy-'.
# The package installs files into /opt/csw/lib/python. For example,
# '/opt/csw/lib/python/site-packages'. However, the catalogname doesn't start
# with 'py_'.
# Missing dependencies of CSWhachoir-parser:
# If you don't know of any reasons to include these dependencies, you might
# remove them:
# ? CSWpy-hachoir-core
If any of the reported errors were false positives, you can
override them pasting the lines below to the GAR recipe.
CHECKPKG_OVERRIDES_CSWhachoir-parser += pkgname-does-not-start-with-CSWpy-
CHECKPKG_OVERRIDES_CSWhachoir-parser += catalogname-does-not-start-with-py_
CHECKPKG_OVERRIDES_CSWhachoir-parser += surplus-dependency|CSWpy-hachoir-core
Please note that checkpkg isn't suggesting you should
use these overrides.  It only informs what the overrides could
look like.  You need to understand what are the reported issues about
and use your best judgement to decide whether to fix the underlying
problems or override them.
-----------------8<--------------------

The messages are displayed above the override lines, so if you have a
lot of errors, they might get scrolled up a lot.  I thought about
saving them to disk somewhere, but it would make the UNCOMMITTED
trigger go off.

I'm still looking for a better way to format these messages.  I don't
want to spam the screen with too much of "READ THIS" kind of text,
because with time, people will go numb.  Perhaps some form of a
bullet-point list?  Ideas?

From Darin.Perusich at cognigencorp.com  Wed Apr 28 23:17:42 2010
From: Darin.Perusich at cognigencorp.com (Darin Perusich)
Date: Wed, 28 Apr 2010 17:17:42 -0400
Subject: [csw-maintainers] gar question
Message-ID: <4BD8A5F6.1070508@cognigencorp.com>

Hello,

I'm trying to build perl 8 from gar and it's failing to find the
PathTools-3.30 dependency. The same thing happens when I attempt to
build perl 10 as well. I thought all that need to be done was checkout
the package, change to the trunk/tag directory, and run gmake. What am I
doing wrong?

-- 
Darin Perusich
Unix Systems Administrator
Cognigen Corporation
395 Youngs Rd.
Williamsville, NY 14221
Phone: 716-633-3463
Email: darinper at cognigencorp.com

From skayser at opencsw.org  Wed Apr 28 23:53:24 2010
From: skayser at opencsw.org (Sebastian Kayser)
Date: Wed, 28 Apr 2010 23:53:24 +0200
Subject: [csw-maintainers] gar question
In-Reply-To: <4BD8A5F6.1070508@cognigencorp.com>
References: <4BD8A5F6.1070508@cognigencorp.com>
Message-ID: <4BD8AE54.2000801@opencsw.org>

Darin Perusich wrote on 28.04.2010 23:17:
> I'm trying to build perl 8 from gar and it's failing to find the
> PathTools-3.30 dependency. The same thing happens when I attempt to
> build perl 10 as well. I thought all that need to be done was checkout
> the package, change to the trunk/tag directory, and run gmake. What am I
> doing wrong?

I can't speak for the perl recipe, only for the GAR workings in general.

Most build recipes in GAR specify the runtime dependencies for a package
(RUNTIME_DEP_PKGS), but not yet the build dependencies (BUILD_DEP_PKGS).
   If a recipe defines the build dependencies, GAR warns you in case any
of the build depencies is missing. I guess the perl recipe doesn't
define them, thus you can run into missing build dependencies.

Either way you have to install such build dependencies manually, GAR
doesn't pull them in automatically. @Dago: How about a GAR target a la
"install-build-deps"?

Sebastian

P.S.: In an ideal world every recipe would define its build
dependencies, so if you feel like adding some or letting the package
maintainer know, please do so.

From Darin.Perusich at cognigencorp.com  Thu Apr 29 00:05:20 2010
From: Darin.Perusich at cognigencorp.com (Darin.Perusich at cognigencorp.com)
Date: Wed, 28 Apr 2010 18:05:20 -0400 (EDT)
Subject: [csw-maintainers] gar question
In-Reply-To: <4BD8AE54.2000801@opencsw.org>
References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org>
Message-ID: <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com>

> Darin Perusich wrote on 28.04.2010 23:17:
>> I'm trying to build perl 8 from gar and it's failing to find the
>> PathTools-3.30 dependency. The same thing happens when I attempt to
>> build perl 10 as well. I thought all that need to be done was checkout
>> the package, change to the trunk/tag directory, and run gmake. What am I
>> doing wrong?
>
> I can't speak for the perl recipe, only for the GAR workings in general.
>
> Most build recipes in GAR specify the runtime dependencies for a package
> (RUNTIME_DEP_PKGS), but not yet the build dependencies (BUILD_DEP_PKGS).
>    If a recipe defines the build dependencies, GAR warns you in case any
> of the build depencies is missing. I guess the perl recipe doesn't
> define them, thus you can run into missing build dependencies.
>
> Either way you have to install such build dependencies manually, GAR
> doesn't pull them in automatically. @Dago: How about a GAR target a la
> "install-build-deps"?

I should have clarified that it's trying to download PathTools-3.30 and
it's not available on any of the mirrors.


From bwalton at opencsw.org  Thu Apr 29 01:59:11 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 28 Apr 2010 19:59:11 -0400
Subject: [csw-maintainers] coreutils
In-Reply-To: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
Message-ID: <1272499094-sup-8467@pinkfloyd.chass.utoronto.ca>

Excerpts from Ben Walton's message of Sat Apr 17 20:06:16 -0400 2010:

Hi All,

> I've created a project page in the wiki to track this:
> http://wiki.opencsw.org/project-coreutils

A quick status update:  We're down to two packages requiring a re-roll
before update testing can begin.

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


From bonivart at opencsw.org  Thu Apr 29 07:30:57 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Thu, 29 Apr 2010 07:30:57 +0200
Subject: [csw-maintainers] gar question
In-Reply-To: <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com>
References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org>
	<39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com>
Message-ID: <l2g625385e31004282230p10c1fd31xae6004e2bec3e4d9@mail.gmail.com>

On Thu, Apr 29, 2010 at 12:05 AM,  <Darin.Perusich at cognigencorp.com> wrote:
> I should have clarified that it's trying to download PathTools-3.30 and
> it's not available on any of the mirrors.

Path::Tools 3.30 seems to have vanished, it's now 3.31 that is
current. Try that.

-- 
/peter

From dam at opencsw.org  Thu Apr 29 09:42:56 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 29 Apr 2010 09:42:56 +0200
Subject: [csw-maintainers] gar question
In-Reply-To: <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com>
References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org>
	<39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com>
Message-ID: <384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org>

Hi Darin,

Am 29.04.2010 um 00:05 schrieb Darin.Perusich at cognigencorp.com:
> I should have clarified that it's trying to download PathTools-3.30 and
> it's not available on any of the mirrors.

There seems to have been some spring cleaning on CPAN removing old versions.
Often we have archived copies at /home/src, but obviously not in this case.
As Peter suggested I would just bump the version and then do
  gmake makesum
to start over.


Best regards

  -- Dago

From dam at opencsw.org  Thu Apr 29 09:50:02 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 29 Apr 2010 09:50:02 +0200
Subject: [csw-maintainers] [csw-buildfarm] svn servers config file
	location changed?
In-Reply-To: <4BD8B840.4020907@opencsw.org>
References: <4BD8B840.4020907@opencsw.org>
Message-ID: <1A794E9A-E846-4B08-B381-0FFD857A5F25@opencsw.org>

Hi,

Am 29.04.2010 um 00:35 schrieb Sebastian Kayser:
> just noticed that svn on the build hosts seems to have forgotten about
> our proxy. truss shows that it tries to open /etc/opt/csw/subversion/servers
> whereas the build hosts only have /etc/subversion/servers. Did the
> location used by svn change?

There seems to be MIGRATECONF missing as in
  http://wiki.opencsw.org/cswclassutils-package#toc12

I guess it should be something like

MIGRATE_FILES = servers config
MIGRATE_SOURCE_DIR = /etc/subversion
MIGRATE_DEST_DIR= /etc/opt/csw/subversion

> @Rupert: Also noticed that the changelog.CSW file in the package is still
> the one from the 1.6.6 version (my comment in the Makefile might have
> been misleading), would you mind updating it for newer versions? :)

Rupert, could you please respin subversion 1.6.9 with the migrateconf-directive?


Best regards

  -- Dago

From Darin.Perusich at cognigencorp.com  Thu Apr 29 17:12:00 2010
From: Darin.Perusich at cognigencorp.com (Darin Perusich)
Date: Thu, 29 Apr 2010 11:12:00 -0400
Subject: [csw-maintainers] gar question
In-Reply-To: <384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org>
References: <4BD8A5F6.1070508@cognigencorp.com>
	<4BD8AE54.2000801@opencsw.org>	<39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com>
	<384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org>
Message-ID: <4BD9A1C0.2030807@cognigencorp.com>

Hi Dago,

On 04/29/2010 03:42 AM, Dagobert Michelsen wrote:
> There seems to have been some spring cleaning on CPAN removing old versions.
> Often we have archived copies at /home/src, but obviously not in this case.
> As Peter suggested I would just bump the version and then do
>   gmake makesum
> to start over.

I've done this and everything appears to build successfully, or at least
I think it has. What do i need to do to create the package, use
createpkg or is gar suppose to do this for me?

-- 
Darin Perusich
Unix Systems Administrator
Cognigen Corporation
395 Youngs Rd.
Williamsville, NY 14221
Phone: 716-633-3463
Email: darinper at cognigencorp.com

From maciej at opencsw.org  Thu Apr 29 17:35:49 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 29 Apr 2010 16:35:49 +0100
Subject: [csw-maintainers] gar question
In-Reply-To: <4BD9A1C0.2030807@cognigencorp.com>
References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org>
	<39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com> 
	<384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org>
	<4BD9A1C0.2030807@cognigencorp.com>
Message-ID: <x2mce97543b1004290835r208ab95i352089f82356f741@mail.gmail.com>

No dia 29 de Abril de 2010 16:12, Darin Perusich
<Darin.Perusich at cognigencorp.com> escreveu:
> I've done this and everything appears to build successfully, or at least
> I think it has. What do i need to do to create the package, use
> createpkg or is gar suppose to do this for me?

Try:

gmake package

From Darin.Perusich at cognigencorp.com  Thu Apr 29 18:04:45 2010
From: Darin.Perusich at cognigencorp.com (Darin Perusich)
Date: Thu, 29 Apr 2010 12:04:45 -0400
Subject: [csw-maintainers] gar question
In-Reply-To: <x2mce97543b1004290835r208ab95i352089f82356f741@mail.gmail.com>
References: <4BD8A5F6.1070508@cognigencorp.com>
	<4BD8AE54.2000801@opencsw.org>	<39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com>
	<384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org>	<4BD9A1C0.2030807@cognigencorp.com>
	<x2mce97543b1004290835r208ab95i352089f82356f741@mail.gmail.com>
Message-ID: <4BD9AE1D.8020107@cognigencorp.com>

On 04/29/2010 11:35 AM, Maciej (Matchek) Blizinski wrote:
> No dia 29 de Abril de 2010 16:12, Darin Perusich
> <Darin.Perusich at cognigencorp.com> escreveu:
>> I've done this and everything appears to build successfully, or at least
>> I think it has. What do i need to do to create the package, use
>> createpkg or is gar suppose to do this for me?
> 
> Try:
> 
> gmake package

That is what I'm doing and I'm getting these "ld.so.1: perl: fatal:
libperl.so.5.8.8:" errors.

everest:perl-5.8.8,REV=2009.11.12$ gmake package
[===== NOW BUILDING: perl-5.8.8 =====]
        [prerequisite] complete for perl.
        [fetch] complete for perl.
        [checksum] complete for perl.
        [checksum-global] complete for perl.
        [checksum-modulated] complete for perl.
[===== NOW BUILDING: perl-5.8.8 MODULATION global: ISA= =====]
        [extract-modulated] complete for perl.
[===== Building modulation 'isa-sparcv8' on host '' =====]
gmake  MODULATION=isa-sparcv8  ISA=sparcv8  merge-modulated
gmake[1]: Entering directory `/opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12'
[===== NOW BUILDING: perl-5.8.8 MODULATION isa-sparcv8: ISA=sparcv8 =====]
        [extract-modulated] complete for perl.
        [patch-modulated] complete for perl.
        [configure-modulated] complete for perl.
        [test-modulated] complete for perl.
 ==> Applying core update: PathTools-3.31
ld.so.1: perl: fatal: libperl.so.5.8.8: open failed: No such file or
directory
Killed
make: Fatal error: No arguments to build
Current working directory
/opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12/work/build-isa-sparcv8/PathTools-3.31
make: Fatal error: Don't know how to make target `test'
Current working directory
/opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12/work/build-isa-sparcv8/PathTools-3.31
make: Fatal error: Don't know how to make target `install'
Current working directory
/opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12/work/build-isa-sparcv8/PathTools-3.31
 ==> Applying core update: CGI.pm-3.44
ld.so.1: perl: fatal: libperl.so.5.8.8: open failed: No such file or
directory
..
..
..
..
gmake[1]: *** [install-core-updates] Error 1
gmake[1]: Leaving directory `/opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12'
gmake: *** [merge-isa-sparcv8] Error 2

-- 
Darin Perusich
Unix Systems Administrator
Cognigen Corporation
395 Youngs Rd.
Williamsville, NY 14221
Phone: 716-633-3463
Email: darinper at cognigencorp.com

From dam at opencsw.org  Thu Apr 29 22:21:22 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 29 Apr 2010 22:21:22 +0200
Subject: [csw-maintainers] gar question
In-Reply-To: <4BD9AE1D.8020107@cognigencorp.com>
References: <4BD8A5F6.1070508@cognigencorp.com>
	<4BD8AE54.2000801@opencsw.org>	<39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com>
	<384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org>	<4BD9A1C0.2030807@cognigencorp.com>
	<x2mce97543b1004290835r208ab95i352089f82356f741@mail.gmail.com>
	<4BD9AE1D.8020107@cognigencorp.com>
Message-ID: <E459C8DD-9230-4EB2-A55A-E525D311F3B3@opencsw.org>

Hi Darin,

Am 29.04.2010 um 18:04 schrieb Darin Perusich:
> That is what I'm doing and I'm getting these "ld.so.1: perl: fatal:
> libperl.so.5.8.8:" errors.

This is a bit difficult. The problem is that the newly binaries are
prepended to PATH and a tool needed by GAR itself has just been build
but is not able to run because the libraries are not really installed
and the binary doesn't have a wrapper to find libraries in relative
locations. Please try
  IGNORE_DESTDIR = 1
and then do a
  gmake repackage


Best regards

  -- Dago

From hson at opencsw.org  Fri Apr 30 01:37:08 2010
From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=)
Date: Fri, 30 Apr 2010 01:37:08 +0200
Subject: [csw-maintainers] opening both 32bit and 64bit shared libs
In-Reply-To: <4BD5BEA6.9070800@cognigencorp.com>
References: <4BD1FA08.2090106@cognigencorp.com>	<j2td57eab941004231425vada5d463kf31ca390eb06b6ac@mail.gmail.com>	<43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com>	<u2vd57eab941004232201wa837d456tea3219aec87c40d9@mail.gmail.com>	<81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org>	<4BD5909D.6080207@cognigencorp.com>	<CEDC1586-595A-43F6-B5C0-8BDB074F3A06@opencsw.org>
	<4BD5BEA6.9070800@cognigencorp.com>
Message-ID: <4BDA1824.7090604@opencsw.org>

I'm just jumping right in the middle of this thread.

Any reason why all amanda binaries are sparcv8+ and not just sparcv8?

>
> I see what you're saying but the behavior I'm seeing is that it's only
> attempting to open the 64bit lib and never the 32bit one, see below.

Incorrect, which you can see when you run LD_DEBUG and grep for NEEDED.

Also you missed something in your grep...

 > <testing9s:~>   grep open /tmp/amtruss.out |grep -v NOENT | grep gthread
 > open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5
 > open("/opt/csw/lib/sparcv8/libgthread-2.0.so.0", O_RDONLY) = 5

Note "sparcv8", not "sparcv9"

The reason why it tries the v8 only once is that it becomes marked 
needed and is never considered again while the v9 is scrapped each time 
and have to be reconsidered.


> I've been in contact with the Amanda developers and they're not sure
> what's going on or how to proceed. From how things appear the problem is
> outside of the amanda libs and is glib2 related.
>
> I've definitely reached a point where I don't know how to proceed so any
> guidance will be greatly appreciated.
>

I think that you have been sidetracked by all this 32/64-stuff.

You have a 32-bit binary and it is only using 32-bit libraries, period!

The reason for the coredump have nothing to do with sparcv9, but as you 
mentioned in your initial mail, the assertion on lib 48 in glib_init.
g_assert = print error and dump core

This can also be seen if you use dbx on the core file that is produced.


t at 1 (l at 1) program terminated by signal ABRT (Abort)
0xffffffffffffffff:     <bad address 0xffffffffffffffff>
Current function is glib_init
    48       g_assert(!g_thread_supported());
(dbx) where 

current thread: t at 1
   [1] 0xff3dc6f8(0xffbfe930, 0xa3, 0x1, 0x6, 0x2, 0x6), at 0xff3dc6f8
   [2] 0xff3d8ea8(0x1, 0x6, 0x0, 0xfec3c000, 0x2, 0x0), at 0xff3d8ea8
   [3] 0xff3dc658(0x1, 0x6, 0x0, 0xfec3c000, 0x2, 0x13), at 0xff3dc658
   [4] raise(0x6, 0x0, 0xffbfeab8, 0xfec3c000, 0xd3ef4, 0xe400), at 
0xfebd0b28
   [5] abort(0x0, 0x1, 0xe45c, 0xfe825bc8, 0xd3ef4, 0xe400), at 0xfebb6e70
   [6] g_assertion_message(0xe5c0, 0xe400, 0xfe83154c, 0xfffea530, 
0x15800, 0xffbfebd4), at 0xfe77902c
   [7] g_assertion_message_expr(0x256fb0, 0xfe977d60, 0x30, 0xfe97e5ef, 
0xacb70, 0x15800), at 0xfe7790a0
=>[8] glib_init(), line 48 in "glib-util.c"
   [9] device_api_init(), line 59 in "device.c"
   [10] boot_Amanda__Device(my_perl = 0x21370, cv = 0x25b2b8), line 4007 
in "Device.c"


For some reason which the amanda developers have to explain, they want 
to initialize libcurl before glib's threading is initialized, but I 
can't see how that code could really work.

----------------------------------------
     /* set up libcurl (this must happen before threading
      * is initialized) */
#ifdef HAVE_LIBCURL
# ifdef G_THREADS_ENABLED
     g_assert(!g_thread_supported());
# endif
     g_assert(curl_global_init(CURL_GLOBAL_ALL) == 0);
#endif

     /* And set up glib's threads */
#if defined(G_THREADS_ENABLED) && !defined(G_THREADS_IMPL_NONE)
     if (g_thread_supported()) {
         return;
     }
     g_thread_init(NULL);
#endif

----------------------------------------

Either you have to compile amanda without threading or without libcurl.

But if they really mean what they write in the comment (that libcurl 
should be initialized before threading, and not that libcurl cannot work 
together with threading), the code maybe should be:
----------------------------------------
#ifdef HAVE_LIBCURL
# ifdef G_THREADS_ENABLED
     if(g_thread_get_initialized ())
        g_assert(!g_thread_supported());
# endif
     g_assert(curl_global_init(CURL_GLOBAL_ALL) == 0);
#endif
----------------------------------------

From dam at opencsw.org  Fri Apr 30 14:40:58 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 30 Apr 2010 14:40:58 +0200
Subject: [csw-maintainers] coreutils
In-Reply-To: <1272499094-sup-8467@pinkfloyd.chass.utoronto.ca>
References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca>
	<1272499094-sup-8467@pinkfloyd.chass.utoronto.ca>
Message-ID: <4B82DC81-95DA-4188-8978-A2F0CFF7BACA@opencsw.org>

Hi Ben,

Am 29.04.2010 um 01:59 schrieb Ben Walton:
> Excerpts from Ben Walton's message of Sat Apr 17 20:06:16 -0400 2010:
>
> Hi All,
>
>> I've created a project page in the wiki to track this:
>> http://wiki.opencsw.org/project-coreutils
>
> A quick status update:  We're down to two packages requiring a re-roll
> before update testing can begin.

As you already updated the Makefile for cswutils feel free to reroll
and take it over.


Best reards

   -- Dago

From dam at baltic-online.de  Wed Apr 28 15:32:11 2010
From: dam at baltic-online.de (Dagobert Michelsen)
Date: Wed, 28 Apr 2010 15:32:11 +0200
Subject: [csw-maintainers] Updating all server to current/
Message-ID: <C18AA021-17E8-43BD-949D-435EEDA683FE@baltic-online.de>

Hi,

I am updating all servers to current/ now.
Please stand by!


Best regards

   -- Dago