From sunfreeware at gmail.com  Wed Jun  4 23:35:16 2008
From: sunfreeware at gmail.com (Steven M. Christensen)
Date: Thu, 05 Jun 2008 02:35:16 -0400
Subject: [companion-integrate] RTI - Update of SFWamnda (amanda) package
Message-ID: <48478924.2020404@gmail.com>

This is a RTI for the update of the SFWamnda (amanda) package to version 
2.6.0p1.

The webrev is at

http://companion.sunfreeware.com/downloads/amandawebrev/

The code has been reviewed and approved with no suggested modifications 
by Paul Cunningham.

Details:

There are a considerable number of changes between the older version of 
amanda and this new one.

Details:

1.  Source code file updated.
2.  Version numbers updated where needed.
3.  New directories added to Targetdirs to match new locations for
     files.
4.  x_postinstall script edited to point to new file locations.
5.  Copyright year updated where needed.
6.  Amanda's configure fails utterly unless LD_LIBRARY_PATH is set so
     that it can find certain libraries.  Therefore, it is set in
     Makefile.sfw.
7.  README.amanda updated to point to new file locations.
8.  prototype_com and install-sfw files required a lot of editing due to
     new files or file locations.


A nightly build on NV 87 is clean and the package installs properly.

Steve Christensen


From Mike.Sullivan at sun.com  Thu Jun  5 13:42:50 2008
From: Mike.Sullivan at sun.com (Mike Sullivan)
Date: Thu, 05 Jun 2008 13:42:50 -0700
Subject: [companion-integrate] RTI - Update of SFWamnda (amanda) package
In-Reply-To: <48478924.2020404@gmail.com>
References: <48478924.2020404@gmail.com>
Message-ID: <48484FCA.1010102@Sun.COM>

Steven M. Christensen wrote:
> This is a RTI for the update of the SFWamnda (amanda) package to version 
> 2.6.0p1.
> 
> The webrev is at
> 
> http://companion.sunfreeware.com/downloads/amandawebrev/
> 
> The code has been reviewed and approved with no suggested modifications 
> by Paul Cunningham.

sorry, but I looked at it :)


> 4.  x_postinstall script edited to point to new file locations.

ick, it actually wants to modify files in base solaris (/etc/dumpdates)?
that seems wrong.

Since the README says this script is editable, shouldn't it be of
type 'e preserve' rather than 'f none' in SFWamnda? Or at least the
README should say 'to copy and edit' rather than 'for editing'?

> 6.  Amanda's configure fails utterly unless LD_LIBRARY_PATH is set so
>      that it can find certain libraries.  Therefore, it is set in
>      Makefile.sfw.

Hmm. Ok. I just hope that means the resulting bits are still ok,
and not that LD_LIBRARY_PATH worked around a build issue but didn't
fix it.

> 7.  README.amanda updated to point to new file locations.

that thing talks about admintool - isn't that long gone?
is there a reason we have a copy of the script in that README as well?
Seems like a great way to get out-of-sync, couldn't the README just
leave the bit saying where the script is, or could we generate the
README itself during the build by combining a README.amanda.tmpl
with x_postinstall?

This bit should probably change now too:

--
Restart the indetd daemon:

         ps -e | grep inet
                 gives pid-of-inetd
         kill -HUP <pid-of-inetd>
--

first of all the inetd typo should be fixed, then shouldn't this be
a svcadm restart?

spell also doesn't like 'authorisation'.

hmm I guess approved but I tend to think the above should be fixed first.

	Mike



From sunfreeware at gmail.com  Tue Jun 10 15:34:49 2008
From: sunfreeware at gmail.com (Steven M. Christensen)
Date: Tue, 10 Jun 2008 18:34:49 -0400
Subject: [companion-integrate] RTI - Update of SFWcvs package
Message-ID: <484F0189.40307@gmail.com>

This is a RTI for the update of SFWcvs to version 1.11.23.

The webrev is at

http://companion.sunfreeware.com/downloads/cvswebrev/

The code has been reviewed and approved by Paul Cunningham.

Details:

1. Added a METADATA file.
2. Updated version numbers and copyright dates where needed.
3. Added new source file.
4. Removed SCCS ids and .SUFFIXES: line.

This simple update builds cleanly in NV 87, the package installs 
properly, and creates a working cvs system.

Note that this cvs is being updated primarily because it needs to be 
included at least in U5 CCD packages.

Steve Christensen


From sunfreeware at gmail.com  Wed Jun 11 01:07:12 2008
From: sunfreeware at gmail.com (Steven M. Christensen)
Date: Wed, 11 Jun 2008 04:07:12 -0400
Subject: [companion-integrate] RTI - Update of SFWtnef
Message-ID: <484F87B0.8000009@gmail.com>

This is a RTI for the update of the SFWtnef package to version 1.4.4.

The webrev is at

http://companion.sunfreeware.com/downloads/tnefwebrev/

The code has been reviewed an approved by Paul Cunningham.

Details:

  1. Updated version number and copyright year where needed.
  2. Bring in new source code file.
  3. Minor update to source URL.

This is a simple update which builds cleanly in NV87, creates a package
that installs properly, and functions normally.

Steve Christensen


From Mike.Sullivan at sun.com  Thu Jun 12 11:15:49 2008
From: Mike.Sullivan at sun.com (Mike Sullivan)
Date: Thu, 12 Jun 2008 11:15:49 -0700
Subject: [companion-integrate] RTI - Update of SFWcvs package
In-Reply-To: <484F0189.40307@gmail.com>
References: <484F0189.40307@gmail.com>
Message-ID: <485167D5.7080307@Sun.COM>

Steven M. Christensen wrote:
> This is a RTI for the update of SFWcvs to version 1.11.23.
> 
> The webrev is at
> 
> http://companion.sunfreeware.com/downloads/cvswebrev/
> 
> The code has been reviewed and approved by Paul Cunningham.
> 
> Details:
> 
> 1. Added a METADATA file.

you might want to have 'gpl2' not gpl these days.

> 2. Updated version numbers and copyright dates where needed.

> 
> This simple update builds cleanly in NV 87, the package installs 
> properly, and creates a working cvs system.
> 
> Note that this cvs is being updated primarily because it needs to be 
> included at least in U5 CCD packages.

I was actually going to ask about that but somebody else did.
I guess I'm ok with having things in that are only for the updates,
but I do begin to wonder if we should move them out of the
mainline so as to be more obvious about it. Of course that doesn't
help with the fact that you need to create source packages too
for it in the updates - maybe you really should have two workspaces
now and be deleting cvs from the nevada one and integrating this
(with source packages) in the updates one?

And I wonder why we are updating to 1.11.23 when nevada has
1.12.13 - shouldn't we do that one or a newer one? Hmm
www.nongnu.org doesn't seem to have 1.12. Isn't www.cvshome.org
the real home? Hmm now I'm all confused as that doesn't have
1.12 either. Oh I see, it's in the 'feature' tree. What is that?

I'm all confused so I guess approved.

	Mike





From Mike.Sullivan at sun.com  Thu Jun 12 11:17:06 2008
From: Mike.Sullivan at sun.com (Mike Sullivan)
Date: Thu, 12 Jun 2008 11:17:06 -0700
Subject: [companion-integrate] RTI - Update of SFWtnef
In-Reply-To: <484F87B0.8000009@gmail.com>
References: <484F87B0.8000009@gmail.com>
Message-ID: <48516822.9030908@Sun.COM>

Steven M. Christensen wrote:
> This is a RTI for the update of the SFWtnef package to version 1.4.4.

approved.


From sunfreeware at gmail.com  Tue Jun 17 02:32:33 2008
From: sunfreeware at gmail.com (Steven M. Christensen)
Date: Tue, 17 Jun 2008 05:32:33 -0400
Subject: [companion-integrate] RTI - Update of SFWxdelta
Message-ID: <485784B1.6090005@gmail.com>

This is a RTI for the update of the SFWxdelta package to version 1.1.4.

The webrev is at

http://companion.sunfreeware.com/downloads/xdeltawebrev/

This has been reviewed and approved by Paul Cunningham.

Details:

This is a very simple update of the Version 1 track of xdelta.

1.  METADATA file added.
2.  Source code file updated.
3.  Version number and copyright year updated where needed.
4.  SCCS ids removed.

This builds properly in a nightly in NV 87.  The package installs 
properly producing a working xdelta system.

Steve Christensen


From Mike.Sullivan at sun.com  Tue Jun 17 11:11:53 2008
From: Mike.Sullivan at sun.com (Mike Sullivan)
Date: Tue, 17 Jun 2008 11:11:53 -0700
Subject: [companion-integrate] RTI - Update of SFWxdelta
In-Reply-To: <485784B1.6090005@gmail.com>
References: <485784B1.6090005@gmail.com>
Message-ID: <4857FE69.1080108@Sun.COM>

Steven M. Christensen wrote:
> This is a RTI for the update of the SFWxdelta package to version 1.1.4.


go for it.



From sunfreeware at gmail.com  Mon Jun 30 11:49:00 2008
From: sunfreeware at gmail.com (Steven M. Christensen)
Date: Mon, 30 Jun 2008 14:49:00 -0400
Subject: [companion-integrate] RTI - Update of SFWfltk to version 1.1.9
Message-ID: <48692A9C.9000806@gmail.com>

This is a RTI for the update of the ftlk
package to version 1.1.9 from release candidate 2 of 1.1.9.

The webrev for this very simple update is at

http://companion.sunfreeware.com/downloads/fltkwebrev/

The code has been reviewed and approved by Paul Cunningham.

Details:

1. Source code file updated.
2. Version numbers updated where needed.

The nightly is clean on NV87, a test pkgadd works, and the
programs appear to run normally.

Steve Christensen


From Mike.Sullivan at sun.com  Mon Jun 30 12:01:12 2008
From: Mike.Sullivan at sun.com (Mike Sullivan)
Date: Mon, 30 Jun 2008 12:01:12 -0700
Subject: [companion-integrate] RTI - Update of SFWfltk to version 1.1.9
In-Reply-To: <48692A9C.9000806@gmail.com>
References: <48692A9C.9000806@gmail.com>
Message-ID: <48692D78.3040509@Sun.COM>

Steven M. Christensen wrote:
> This is a RTI for the update of the ftlk
> package to version 1.1.9 from release candidate 2 of 1.1.9.
> 
> The webrev for this very simple update is at
> 
> http://companion.sunfreeware.com/downloads/fltkwebrev/
> 
> The code has been reviewed and approved by Paul Cunningham.
> 
> Details:
> 
> 1. Source code file updated.
> 2. Version numbers updated where needed.

so approved but... the transition almost looks backwards,
as if we're going from a newer version (1.1.9.2) to an older
one (1.1.9) when we're not - the .2 was just a way to show
it was rc2. However I think this now shows me that that's not
a good way to do that :) So I think in the future, or if there
are any that are currently done this way, we should not
convert rc or alpha/beta type indications into numbers in the
pkginfo version fields. Maybe it's a case where we should put
the version in text in the DESC field if we think it's needed,
or just try incredibly hard not to ship such versions? I know
there may be a few times when the real stable thing is still
not labeled as an 'official' release but those could be exceptions
where we put the version in DESC.

	Mike


From sunfreeware at gmail.com  Mon Jun 30 12:21:06 2008
From: sunfreeware at gmail.com (Steven M. Christensen)
Date: Mon, 30 Jun 2008 15:21:06 -0400
Subject: [companion-integrate] RTI - Update of SFWfltk to version 1.1.9
In-Reply-To: <48692D78.3040509@Sun.COM>
References: <48692A9C.9000806@gmail.com> <48692D78.3040509@Sun.COM>
Message-ID: <48693222.9010203@gmail.com>

Mike -

I completely agree with your assessment of this.  Yet, I am facing this 
sort of issue right now.   The current fetchmail package is 6.3.8.  It 
was announced on the fetchmail site last week that there are two denial 
of service vulnerabilities in 6.3.8 that are corrected in 6.3.9-p2. 
There is no indication on when a 6.3.9 final release will be done.  So, 
do we offer 6.3.9-p2 now or wait?   I do not like having a vulnerable 
package.   I can build the p2 package immediately or wait for an 
official release.

Thoughts?

Steve C.

Mike Sullivan wrote:
> Steven M. Christensen wrote:
>> This is a RTI for the update of the ftlk
>> package to version 1.1.9 from release candidate 2 of 1.1.9.
>>
>> The webrev for this very simple update is at
>>
>> http://companion.sunfreeware.com/downloads/fltkwebrev/
>>
>> The code has been reviewed and approved by Paul Cunningham.
>>
>> Details:
>>
>> 1. Source code file updated.
>> 2. Version numbers updated where needed.
> 
> so approved but... the transition almost looks backwards,
> as if we're going from a newer version (1.1.9.2) to an older
> one (1.1.9) when we're not - the .2 was just a way to show
> it was rc2. However I think this now shows me that that's not
> a good way to do that :) So I think in the future, or if there
> are any that are currently done this way, we should not
> convert rc or alpha/beta type indications into numbers in the
> pkginfo version fields. Maybe it's a case where we should put
> the version in text in the DESC field if we think it's needed,
> or just try incredibly hard not to ship such versions? I know
> there may be a few times when the real stable thing is still
> not labeled as an 'official' release but those could be exceptions
> where we put the version in DESC.
> 
>     Mike
> 


From Mike.Sullivan at sun.com  Mon Jun 30 12:30:22 2008
From: Mike.Sullivan at sun.com (Mike Sullivan)
Date: Mon, 30 Jun 2008 12:30:22 -0700
Subject: [companion-integrate] RTI - Update of SFWfltk to version 1.1.9
In-Reply-To: <48693222.9010203@gmail.com>
References: <48692A9C.9000806@gmail.com> <48692D78.3040509@Sun.COM>
	<48693222.9010203@gmail.com>
Message-ID: <4869344E.6070206@Sun.COM>

Steven M. Christensen wrote:
> Mike -
> 
> I completely agree with your assessment of this.  Yet, I am facing this 
> sort of issue right now.   The current fetchmail package is 6.3.8.  It 
> was announced on the fetchmail site last week that there are two denial 
> of service vulnerabilities in 6.3.8 that are corrected in 6.3.9-p2. 
> There is no indication on when a 6.3.9 final release will be done.  So, 
> do we offer 6.3.9-p2 now or wait?   I do not like having a vulnerable 
> package.   I can build the p2 package immediately or wait for an 
> official release.

Yes so this might be one of the exceptions - and you might want to
ask Stephen Talley if he knows since he bundled 6.3.8 and I only
see one patch (though maybe it contains both). I'd worry about
that one more.

So one thing you could do is apply patches to 6.3.8 (if they exist)
which would let you create 6.3.8.2 (I guess). Or this could be one
where you'd put in 6.3.9 but call it 6.3.9-p2 in the DESC (unless
there's a better name).

	Mike


> 
> Thoughts?
> 
> Steve C.
> 
> Mike Sullivan wrote:
>> Steven M. Christensen wrote:
>>> This is a RTI for the update of the ftlk
>>> package to version 1.1.9 from release candidate 2 of 1.1.9.
>>>
>>> The webrev for this very simple update is at
>>>
>>> http://companion.sunfreeware.com/downloads/fltkwebrev/
>>>
>>> The code has been reviewed and approved by Paul Cunningham.
>>>
>>> Details:
>>>
>>> 1. Source code file updated.
>>> 2. Version numbers updated where needed.
>>
>> so approved but... the transition almost looks backwards,
>> as if we're going from a newer version (1.1.9.2) to an older
>> one (1.1.9) when we're not - the .2 was just a way to show
>> it was rc2. However I think this now shows me that that's not
>> a good way to do that :) So I think in the future, or if there
>> are any that are currently done this way, we should not
>> convert rc or alpha/beta type indications into numbers in the
>> pkginfo version fields. Maybe it's a case where we should put
>> the version in text in the DESC field if we think it's needed,
>> or just try incredibly hard not to ship such versions? I know
>> there may be a few times when the real stable thing is still
>> not labeled as an 'official' release but those could be exceptions
>> where we put the version in DESC.
>>
>>     Mike
>>
>