headers
Hanspeter Niederstrasser | 1 May 2010 13:07

distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)

libnessus3-ssl is marked as Restrictive (links to OpenSSL) and the 
source is now unavailable upstream (license change for newer versions 
and dead FTP server).  fink fetch libnessus3-ssl then fails to build, 
only checking Source: defined in the .info file.

However, the tarball _is_ available from 
<http://distfiles.master.finkmirrors.net/>, probably because of 
libnessus3 (non-ssl).  This brings up some questions:

1) Should packages marked as Restrictive be able to check mirrors if 
they can't find the source upstream?

2) Should a new license option be used for packages marked as 
restrictive because of OpenSSL linkage (or other similar situation)? 
Fink policy says "will not distribute binaries", but in practice this 
also means that the source tarball is not distributed/mirrored.  Most 
packages that fall into this category are GPL, so the source alone can 
be distributed.  Having a new License option, Restrictive/SourceOnly for 
example, to complement Restrictive/Distributable would take care of 
these packages.

Hanspeter

------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
(Continue reading)

Permalink | Reply | 5 comments |
headers
Alexander Hansen | 1 May 2010 15:13
Picon
Gravatar

Re: distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)


On 5/1/10 7:07 AM, Hanspeter Niederstrasser wrote:
> libnessus3-ssl is marked as Restrictive (links to OpenSSL) and the 
> source is now unavailable upstream (license change for newer versions 
> and dead FTP server).  fink fetch libnessus3-ssl then fails to build, 
> only checking Source: defined in the .info file.
> 
> However, the tarball _is_ available from 
> <http://distfiles.master.finkmirrors.net/>, probably because of 
> libnessus3 (non-ssl).  This brings up some questions:
> 
> 1) Should packages marked as Restrictive be able to check mirrors if 
> they can't find the source upstream?
> 

If the sources are legally redistributable and therefore mirror-able,
that sounds reasonable.

> 2) Should a new license option be used for packages marked as 
> restrictive because of OpenSSL linkage (or other similar situation)? 
> Fink policy says "will not distribute binaries", but in practice this 
> also means that the source tarball is not distributed/mirrored.  Most 
> packages that fall into this category are GPL, so the source alone can 
> be distributed.  Having a new License option, Restrictive/SourceOnly for 
> example, to complement Restrictive/Distributable would take care of 
> these packages.
> 
> Hanspeter
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
David R. Morrison | 1 May 2010 15:22
Favicon

Re: distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)


On May 1, 2010, at 6:13 AM, Alexander Hansen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 5/1/10 7:07 AM, Hanspeter Niederstrasser wrote:
>> libnessus3-ssl is marked as Restrictive (links to OpenSSL) and the
>> source is now unavailable upstream (license change for newer versions
>> and dead FTP server).  fink fetch libnessus3-ssl then fails to build,
>> only checking Source: defined in the .info file.
>>
>> However, the tarball _is_ available from
>> <http://distfiles.master.finkmirrors.net/>, probably because of
>> libnessus3 (non-ssl).  This brings up some questions:
>>
>> 1) Should packages marked as Restrictive be able to check mirrors if
>> they can't find the source upstream?
>>
>
> If the sources are legally redistributable and therefore mirror-able,
> that sounds reasonable.

There are definitely cases in which no permission to distribute  
source has been given.  That's why, when we set up distfiles, we  
extended the policy on non-distribution to include "not mirrored on  
our distfiles servers".

>
>> 2) Should a new license option be used for packages marked as
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jack Howarth | 1 May 2010 21:11
Picon

autoconf 2.64 package needed

   FYI, Steven Bosscher has made amazing progress towards
implementing Mach-O link time optimization for FSF gcc
working on my machine under fink...

http://gcc.gnu.org/ml/gcc-bugs/2010-05/msg00035.html

One issue I have run into though is how to reliably produce
the necessary fink autoconf-2.64 package for regenerating
configure files in FSF gcc (which requires exactly 2.64).
Steven is now testing under i386 fink and I ran into the
same random issue as before when trying to replace the
stock autoconf file in unstable with one for 2.64. Using
the autoconf.info of...

Package: autoconf
Version: 2.64
Revision: 200
Epoch: 2
Depends: m4 (>= 1.4.11)
BuildDepends: texi2html, fink (>= 0.24.12)
Conflicts: autoconf2.13, autoconf25 (<= 2.54-1), autoconf2.6
Replaces: autoconf2.13, autoconf25 (<= 2.54-1), autoconf2.6
Source: mirror:gnu:autoconf/autoconf-%v.tar.bz2
Source-MD5: ef400d672005e0be21e0d20648169074 
Patchfile: autoconf.patch
Patchfile-MD5: 8b60b50f8a73e87cc5b2136923502427
ConfigureParams: --infodir='${prefix}/share/info' --mandir='${prefix}/share/man' --program-suffix=-%v
NoSetMAKEFLAGS: true
SetMAKEFLAGS: -j1
CompileScript: <<
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jack Howarth | 1 May 2010 21:15
Picon

cvs commit access

David,
   Any chance I can get back my cvs commit access
for checking in the gcc4x and llvm related packages?
I think Peter is getting tried of having to do all
of my checkins.
            Jack
ps I'll see if I can get clean backports of the
new Mach-O Link Time Optimization patches for
gcc-4_5-branch and update the gcc45 package to use
them. It looks as if Steve may have the patches
for gcc trunk finished by the end of this weekend.

------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Permalink | Reply | 3 comments |
headers
sebastien masson | 1 May 2010 21:25
Picon

update of cdo

Hello,
Would it be possible to update cdo package to the latest version:  
1.4.4 ?
thank you,

Sebastien

------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Permalink | Reply | 1 comment |
headers
Alexander Hansen | 1 May 2010 22:40
Picon
Gravatar

Re: autoconf 2.64 package needed


On 5/1/10 3:11 PM, Jack Howarth wrote:
>    FYI, Steven Bosscher has made amazing progress towards
> implementing Mach-O link time optimization for FSF gcc
> working on my machine under fink...
> 
> http://gcc.gnu.org/ml/gcc-bugs/2010-05/msg00035.html
> 
> One issue I have run into though is how to reliably produce
> the necessary fink autoconf-2.64 package for regenerating
> configure files in FSF gcc (which requires exactly 2.64).
> Steven is now testing under i386 fink and I ran into the
> same random issue as before when trying to replace the
> stock autoconf file in unstable with one for 2.64. Using
> the autoconf.info of...
> 
> 

<snip>

From the DescDetail of the current autoconf from unstable:

"This package installs Autoconf version 2.63. It has some compatibility
problems with older packages. If you want to work on a package that
requires
Autoconf 2.13, install the autoconf2.13 package instead. Because of
some major improvements in autoconf-2.64, that version is not
compatible either, for latest autoconf, please install the autoconf2.6
package."
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jack Howarth | 1 May 2010 22:50
Picon

Re: autoconf 2.64 package needed

Alexander,
   No, FSF gcc locks onto a specific version of autoconf
and the process of getting them to bump to a newer version
can take quite awhile. Read...

http://www.pubbs.net/200812/gcc/2456-re-gcc-and-autoconf-261.html

I guess autoconf itself doesn't have to be 2.64 but we need
an alternate autoconf2.64 package which FSF gcc developers
can use under fink.
             Jack

On Sat, May 01, 2010 at 04:40:21PM -0400, Alexander Hansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 5/1/10 3:11 PM, Jack Howarth wrote:
> >    FYI, Steven Bosscher has made amazing progress towards
> > implementing Mach-O link time optimization for FSF gcc
> > working on my machine under fink...
> > 
> > http://gcc.gnu.org/ml/gcc-bugs/2010-05/msg00035.html
> > 
> > One issue I have run into though is how to reliably produce
> > the necessary fink autoconf-2.64 package for regenerating
> > configure files in FSF gcc (which requires exactly 2.64).
> > Steven is now testing under i386 fink and I ran into the
> > same random issue as before when trying to replace the
> > stock autoconf file in unstable with one for 2.64. Using
> > the autoconf.info of...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Costabel | 1 May 2010 23:34
Picon

Re: distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)

David R. Morrison wrote:
[]
> However, I can't think of a case other than the openssl nonsense  
> where this would apply.  And many openssl packages have been  
> converted to use the openssl which ships with os x (rather than  
> fink's) which makes it ok to distribute.  So I'm thinking that it  
> might be better to spend energy in revising those packages, rather  
> than in writing fink code (and distfiles code) to handle a new  
> special case.

A healthier option would be to simply ignore that silly pissing contest 
between gnu and openssl and declare gpl packages as gpl, full stop. To 
any non-American at least it is clear that we are splitting hairs here 
that don't even exist, since Fink has stopped distributing binaries long 
ago.

--

-- 
Martin

------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Permalink | Reply | 0 comments |
headers
Hanspeter Niederstrasser | 2 May 2010 01:26

Re: update of cdo

On 5/1/10 3:25 PM, sebastien masson wrote:
> Hello,
> Would it be possible to update cdo package to the latest version:
> 1.4.4 ?
> thank you,

cdo is currently not maintained by anyone.  However, it is possible for 
you to try to update your local version and you can then report back if 
it worked (and the cdo .info file looks simple enough that a simple 
version bump might be enough to update it).  If you're willing to try 
this, follow the example directions from here 
<http://finkers.wordpress.com/2009/07/24/creating-local-packages/>.  You 
can ignore the SetCFLAGS steps from that example because it's specific 
to that package, but the rest should apply, changing the file names 
where appropriate.

Hanspeter

------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Permalink | Reply | 0 comments |

Gmane