Re: [Fink-devel] Handling flat_namespace on 10.10+

[Jack Howarth]

What else has flat_namespace in fink? I am only aware of two packages
that absolutely have to be built with flat_namespace. Openmpi and the
libXt shared lib for motif compatibility. Most everything else can be
upgraded and are producing the flat_namespace linkages on 10.10 due to
the broken configure files generated from the old buggy libtool.


On Tue, Apr 28, 2015 at 6:10 PM, TheSin  wrote:
> yeah I tried to build something with flat_namespace today just so I could see 
> the symbols file but the validator wouldn’t pass, I guess I could have turned 
> off -m though ;) I’ll try again since I just thought of that now.
> ---
> TS
> http://www.southofheaven.org/
> Life begins and ends with chaos, live between the chaos!
>
>> On Apr 28, 2015, at 3:15 PM, Jack Howarth  wrote:
>>
>> Note that we are using the absence of TWOLEVEL in the otool -hv output
>> in Validation.pm...
>>
>>   if (open (OTOOL, "$otool -hv '$dylib_temp' 
>> |")) {
>>; ; ; #
>> skip first three lines
>>unless (  =~ /TWOLEVEL/ ) {
>>print "Error:
>> $dylib_temp appears to have been linked using a flat namespace.\n";
>>print "   If this
>> package BuildDepends on libtool2, make sure that you use\n";
>>print "
>> BuildDepends: libtool2 (>= 2.4.2-4).\n";
>>print "   and use
>> autoreconf to regenerate the configure script.\n";
>>print "   If the
>> package doesn't BuildDepend on libtool2, you'll need to\n";
>>print "   update
>> its build procedure to avoid passing\n";
>>print "
>> -Wl,-flat_namespace\n";
>>print "   when
>> linking libraries.\n";
>>$looks_good = 0;
>>}
>>close (OTOOL);
>>}
>>
>> On Tue, Apr 28, 2015 at 5:12 PM, Jack Howarth  
>> wrote:
>>> There are a couple of trivial tests for flat_namespace linkage.
>>>
>>> %  /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind
>>> /sw/lib/openmpi/libmpi.1.dylib
>>> bind information:
>>> segment section  addresstypeaddend dylib
>>> symbol
>>> __DATA  __got0x001CC000pointer  0 flat-namespace
>>> _ADIOI_DFLT_ERR_HANDLER
>>> __DATA  __got0x001CC008pointer  0 flat-namespace
>>> _ADIOI_Datarep_head
>>>
>>> or
>>>
>>> % otool -hv /sw/lib/openmpi/libmpi.1.dylib
>>> /sw/lib/openmpi/libmpi.1.dylib:
>>> Mach header
>>>  magic cputype cpusubtype  capsfiletype ncmds sizeofcmds  flags
>>> MH_MAGIC_64  X86_64ALL  0x00   DYLIB17   1888
>>> DYLDLINK NO_REEXPORTED_DYLIBS
>>>
>>> where the absence of TWOLEVEL indicates flat_namespace linkage...
>>>
>>> % otool -hvi /sw/lib/libfftw3.3.dylib
>>> /sw/lib/libfftw3.3.dylib:
>>> Mach header
>>>  magic cputype cpusubtype  capsfiletype ncmds sizeofcmds  flags
>>> MH_MAGIC_64  X86_64ALL  0x00   DYLIB15   1768
>>> NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS
>>>
>>> On Tue, Apr 28, 2015 at 1:46 PM, TheSin  wrote:
 if we upgrade to my PR I think we could use the symbols files in the dpkg 
 info die to find flat libs, I’m not 100% certain as I’d need an example to 
 test, but if flat_namespace creates a symbol it would be possible, it 
 could even be a trigger to process and sort all libs known to use 
 flat_namespace, then just check that.  Either options is pretty easy to do.
 ---
 TS
 http://www.southofheaven.org/
 Life begins and ends with chaos, live between the chaos!

> On Apr 28, 2015, at 11:14 AM, Alexander Hansen 
>  wrote:
>
>
>> On Apr 28, 2015, at 09:41, Alexander Hansen 
>>  wrote:
>>
>>
>>> On Apr 28, 2015, at 09:36, Jack Howarth  
>>> wrote:
>>>
>>> Looking at the code, it seem we would have to do this check in sub
>>> validate_dpkg_file and use global boolean called
>>> skip_flat_namespace_check or such. In validate_dpkg_file, regex check
>>> $dpkg_filename against both openmpi-shlibs_*.deb or openmpi_*.deb. If
>>> either match, set skip_flat_namespace_check to true
>>> and otherwise to false. Then add skip_flat_namespace_check as a
>>> conditional in the...
>>>
>>> if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {
>>>
>>> state that controls the flat namespace checks on each file.
>>>
>>
>> As Daniel said, adding a new .info field (if that’s what you mean by 
>> global boolean) involves adding on another hack

Re: [Fink-devel] Handling flat_namespace on 10.10+

[TheSin]

yeah I tried to build something with flat_namespace today just so I could see 
the symbols file but the validator wouldn’t pass, I guess I could have turned 
off -m though ;) I’ll try again since I just thought of that now.
---
TS
http://www.southofheaven.org/
Life begins and ends with chaos, live between the chaos!

> On Apr 28, 2015, at 3:15 PM, Jack Howarth  wrote:
> 
> Note that we are using the absence of TWOLEVEL in the otool -hv output
> in Validation.pm...
> 
>   if (open (OTOOL, "$otool -hv '$dylib_temp' |")) 
> {
>; ; ; #
> skip first three lines
>unless (  =~ /TWOLEVEL/ ) {
>print "Error:
> $dylib_temp appears to have been linked using a flat namespace.\n";
>print "   If this
> package BuildDepends on libtool2, make sure that you use\n";
>print "
> BuildDepends: libtool2 (>= 2.4.2-4).\n";
>print "   and use
> autoreconf to regenerate the configure script.\n";
>print "   If the
> package doesn't BuildDepend on libtool2, you'll need to\n";
>print "   update
> its build procedure to avoid passing\n";
>print "
> -Wl,-flat_namespace\n";
>print "   when
> linking libraries.\n";
>$looks_good = 0;
>}
>close (OTOOL);
>}
> 
> On Tue, Apr 28, 2015 at 5:12 PM, Jack Howarth  
> wrote:
>> There are a couple of trivial tests for flat_namespace linkage.
>> 
>> %  /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind
>> /sw/lib/openmpi/libmpi.1.dylib
>> bind information:
>> segment section  addresstypeaddend dylib
>> symbol
>> __DATA  __got0x001CC000pointer  0 flat-namespace
>> _ADIOI_DFLT_ERR_HANDLER
>> __DATA  __got0x001CC008pointer  0 flat-namespace
>> _ADIOI_Datarep_head
>> 
>> or
>> 
>> % otool -hv /sw/lib/openmpi/libmpi.1.dylib
>> /sw/lib/openmpi/libmpi.1.dylib:
>> Mach header
>>  magic cputype cpusubtype  capsfiletype ncmds sizeofcmds  flags
>> MH_MAGIC_64  X86_64ALL  0x00   DYLIB17   1888
>> DYLDLINK NO_REEXPORTED_DYLIBS
>> 
>> where the absence of TWOLEVEL indicates flat_namespace linkage...
>> 
>> % otool -hvi /sw/lib/libfftw3.3.dylib
>> /sw/lib/libfftw3.3.dylib:
>> Mach header
>>  magic cputype cpusubtype  capsfiletype ncmds sizeofcmds  flags
>> MH_MAGIC_64  X86_64ALL  0x00   DYLIB15   1768
>> NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS
>> 
>> On Tue, Apr 28, 2015 at 1:46 PM, TheSin  wrote:
>>> if we upgrade to my PR I think we could use the symbols files in the dpkg 
>>> info die to find flat libs, I’m not 100% certain as I’d need an example to 
>>> test, but if flat_namespace creates a symbol it would be possible, it could 
>>> even be a trigger to process and sort all libs known to use flat_namespace, 
>>> then just check that.  Either options is pretty easy to do.
>>> ---
>>> TS
>>> http://www.southofheaven.org/
>>> Life begins and ends with chaos, live between the chaos!
>>> 
 On Apr 28, 2015, at 11:14 AM, Alexander Hansen 
  wrote:
 
 
> On Apr 28, 2015, at 09:41, Alexander Hansen  
> wrote:
> 
> 
>> On Apr 28, 2015, at 09:36, Jack Howarth  
>> wrote:
>> 
>> Looking at the code, it seem we would have to do this check in sub
>> validate_dpkg_file and use global boolean called
>> skip_flat_namespace_check or such. In validate_dpkg_file, regex check
>> $dpkg_filename against both openmpi-shlibs_*.deb or openmpi_*.deb. If
>> either match, set skip_flat_namespace_check to true
>> and otherwise to false. Then add skip_flat_namespace_check as a
>> conditional in the...
>> 
>> if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {
>> 
>> state that controls the flat namespace checks on each file.
>> 
> 
> As Daniel said, adding a new .info field (if that’s what you mean by 
> global boolean) involves adding on another hack to the .deb control field 
> for 2 packages out of more than 1.  For something that end-users 
> never see.
> 
> It’d be easier just to get Brendan to whitelist the packages for his auto 
> builder.
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
> 
 
 Oh wait, I re-parsed that, so I think I understand better what you’re 
 getting at.  And I don’t think it will work as intended, since I believe 
 $validate_dpkg_file is run only 

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Jack Howarth]

Note that we are using the absence of TWOLEVEL in the otool -hv output
in Validation.pm...

   if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {
; ; ; #
skip first three lines
unless (  =~ /TWOLEVEL/ ) {
print "Error:
$dylib_temp appears to have been linked using a flat namespace.\n";
print "   If this
package BuildDepends on libtool2, make sure that you use\n";
print "
BuildDepends: libtool2 (>= 2.4.2-4).\n";
print "   and use
autoreconf to regenerate the configure script.\n";
print "   If the
package doesn't BuildDepend on libtool2, you'll need to\n";
print "   update
its build procedure to avoid passing\n";
print "
-Wl,-flat_namespace\n";
print "   when
linking libraries.\n";
$looks_good = 0;
}
close (OTOOL);
}

On Tue, Apr 28, 2015 at 5:12 PM, Jack Howarth  wrote:
> There are a couple of trivial tests for flat_namespace linkage.
>
> %  /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind
> /sw/lib/openmpi/libmpi.1.dylib
> bind information:
> segment section  addresstypeaddend dylibsymbol
> __DATA  __got0x001CC000pointer  0 flat-namespace
> _ADIOI_DFLT_ERR_HANDLER
> __DATA  __got0x001CC008pointer  0 flat-namespace
> _ADIOI_Datarep_head
>
> or
>
> % otool -hv /sw/lib/openmpi/libmpi.1.dylib
> /sw/lib/openmpi/libmpi.1.dylib:
> Mach header
>   magic cputype cpusubtype  capsfiletype ncmds sizeofcmds  flags
> MH_MAGIC_64  X86_64ALL  0x00   DYLIB17   1888
> DYLDLINK NO_REEXPORTED_DYLIBS
>
> where the absence of TWOLEVEL indicates flat_namespace linkage...
>
> % otool -hvi /sw/lib/libfftw3.3.dylib
> /sw/lib/libfftw3.3.dylib:
> Mach header
>   magic cputype cpusubtype  capsfiletype ncmds sizeofcmds  flags
> MH_MAGIC_64  X86_64ALL  0x00   DYLIB15   1768
> NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS
>
> On Tue, Apr 28, 2015 at 1:46 PM, TheSin  wrote:
>> if we upgrade to my PR I think we could use the symbols files in the dpkg 
>> info die to find flat libs, I’m not 100% certain as I’d need an example to 
>> test, but if flat_namespace creates a symbol it would be possible, it could 
>> even be a trigger to process and sort all libs known to use flat_namespace, 
>> then just check that.  Either options is pretty easy to do.
>> ---
>> TS
>> http://www.southofheaven.org/
>> Life begins and ends with chaos, live between the chaos!
>>
>>> On Apr 28, 2015, at 11:14 AM, Alexander Hansen 
>>>  wrote:
>>>
>>>
 On Apr 28, 2015, at 09:41, Alexander Hansen  
 wrote:


> On Apr 28, 2015, at 09:36, Jack Howarth  wrote:
>
> Looking at the code, it seem we would have to do this check in sub
> validate_dpkg_file and use global boolean called
> skip_flat_namespace_check or such. In validate_dpkg_file, regex check
> $dpkg_filename against both openmpi-shlibs_*.deb or openmpi_*.deb. If
> either match, set skip_flat_namespace_check to true
> and otherwise to false. Then add skip_flat_namespace_check as a
> conditional in the...
>
> if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {
>
> state that controls the flat namespace checks on each file.
>

 As Daniel said, adding a new .info field (if that’s what you mean by 
 global boolean) involves adding on another hack to the .deb control field 
 for 2 packages out of more than 1.  For something that end-users never 
 see.

 It’d be easier just to get Brendan to whitelist the packages for his auto 
 builder.
 --
 Alexander Hansen, Ph.D.
 Fink User Liaison

>>>
>>> Oh wait, I re-parsed that, so I think I understand better what you’re 
>>> getting at.  And I don’t think it will work as intended, since I believe 
>>> $validate_dpkg_file is run only on actual .debs and not on root directories 
>>> before they get packed.
>>>
>>> In principle we could just check individual dylib’s names against a 
>>> whitelist of filename patterns and if they match we can skip the 
>>> flat_namespace check via a ‘next’.
>>>
>>> --
>>> Alexander Hansen, Ph.D.
>>> Fink User Liaison
>>>
>>>
>>> --
>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring suppo

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Jack Howarth]

There are a couple of trivial tests for flat_namespace linkage.

%  /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind
/sw/lib/openmpi/libmpi.1.dylib
bind information:
segment section  addresstypeaddend dylibsymbol
__DATA  __got0x001CC000pointer  0 flat-namespace
_ADIOI_DFLT_ERR_HANDLER
__DATA  __got0x001CC008pointer  0 flat-namespace
_ADIOI_Datarep_head

or

% otool -hv /sw/lib/openmpi/libmpi.1.dylib
/sw/lib/openmpi/libmpi.1.dylib:
Mach header
  magic cputype cpusubtype  capsfiletype ncmds sizeofcmds  flags
MH_MAGIC_64  X86_64ALL  0x00   DYLIB17   1888
DYLDLINK NO_REEXPORTED_DYLIBS

where the absence of TWOLEVEL indicates flat_namespace linkage...

% otool -hvi /sw/lib/libfftw3.3.dylib
/sw/lib/libfftw3.3.dylib:
Mach header
  magic cputype cpusubtype  capsfiletype ncmds sizeofcmds  flags
MH_MAGIC_64  X86_64ALL  0x00   DYLIB15   1768
NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS

On Tue, Apr 28, 2015 at 1:46 PM, TheSin  wrote:
> if we upgrade to my PR I think we could use the symbols files in the dpkg 
> info die to find flat libs, I’m not 100% certain as I’d need an example to 
> test, but if flat_namespace creates a symbol it would be possible, it could 
> even be a trigger to process and sort all libs known to use flat_namespace, 
> then just check that.  Either options is pretty easy to do.
> ---
> TS
> http://www.southofheaven.org/
> Life begins and ends with chaos, live between the chaos!
>
>> On Apr 28, 2015, at 11:14 AM, Alexander Hansen  
>> wrote:
>>
>>
>>> On Apr 28, 2015, at 09:41, Alexander Hansen  
>>> wrote:
>>>
>>>
 On Apr 28, 2015, at 09:36, Jack Howarth  wrote:

 Looking at the code, it seem we would have to do this check in sub
 validate_dpkg_file and use global boolean called
 skip_flat_namespace_check or such. In validate_dpkg_file, regex check
 $dpkg_filename against both openmpi-shlibs_*.deb or openmpi_*.deb. If
 either match, set skip_flat_namespace_check to true
 and otherwise to false. Then add skip_flat_namespace_check as a
 conditional in the...

 if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {

 state that controls the flat namespace checks on each file.

>>>
>>> As Daniel said, adding a new .info field (if that’s what you mean by global 
>>> boolean) involves adding on another hack to the .deb control field for 2 
>>> packages out of more than 1.  For something that end-users never see.
>>>
>>> It’d be easier just to get Brendan to whitelist the packages for his auto 
>>> builder.
>>> --
>>> Alexander Hansen, Ph.D.
>>> Fink User Liaison
>>>
>>
>> Oh wait, I re-parsed that, so I think I understand better what you’re 
>> getting at.  And I don’t think it will work as intended, since I believe 
>> $validate_dpkg_file is run only on actual .debs and not on root directories 
>> before they get packed.
>>
>> In principle we could just check individual dylib’s names against a 
>> whitelist of filename patterns and if they match we can skip the 
>> flat_namespace check via a ‘next’.
>>
>> --
>> Alexander Hansen, Ph.D.
>> Fink User Liaison
>>
>>
>> --
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> ___
>> Fink-devel mailing list
>> Fink-devel@lists.sourceforge.net
>> List archive:
>> http://news.gmane.org/gmane.os.apple.fink.devel
>> Subscription management:
>> https://lists.sourceforge.net/lists/listinfo/fink-devel
>

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[TheSin]

if we upgrade to my PR I think we could use the symbols files in the dpkg info 
die to find flat libs, I’m not 100% certain as I’d need an example to test, but 
if flat_namespace creates a symbol it would be possible, it could even be a 
trigger to process and sort all libs known to use flat_namespace, then just 
check that.  Either options is pretty easy to do.
---
TS
http://www.southofheaven.org/
Life begins and ends with chaos, live between the chaos!

> On Apr 28, 2015, at 11:14 AM, Alexander Hansen  
> wrote:
> 
> 
>> On Apr 28, 2015, at 09:41, Alexander Hansen  
>> wrote:
>> 
>> 
>>> On Apr 28, 2015, at 09:36, Jack Howarth  wrote:
>>> 
>>> Looking at the code, it seem we would have to do this check in sub
>>> validate_dpkg_file and use global boolean called
>>> skip_flat_namespace_check or such. In validate_dpkg_file, regex check
>>> $dpkg_filename against both openmpi-shlibs_*.deb or openmpi_*.deb. If
>>> either match, set skip_flat_namespace_check to true
>>> and otherwise to false. Then add skip_flat_namespace_check as a
>>> conditional in the...
>>> 
>>> if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {
>>> 
>>> state that controls the flat namespace checks on each file.
>>> 
>> 
>> As Daniel said, adding a new .info field (if that’s what you mean by global 
>> boolean) involves adding on another hack to the .deb control field for 2 
>> packages out of more than 1.  For something that end-users never see.  
>> 
>> It’d be easier just to get Brendan to whitelist the packages for his auto 
>> builder.
>> -- 
>> Alexander Hansen, Ph.D.
>> Fink User Liaison
>> 
> 
> Oh wait, I re-parsed that, so I think I understand better what you’re getting 
> at.  And I don’t think it will work as intended, since I believe 
> $validate_dpkg_file is run only on actual .debs and not on root directories 
> before they get packed.
> 
> In principle we could just check individual dylib’s names against a whitelist 
> of filename patterns and if they match we can skip the flat_namespace check 
> via a ‘next’.
> 
> -- 
> Alexander Hansen, Ph.D.
> Fink User Liaison
> 
> 
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Alexander Hansen]

> On Apr 28, 2015, at 09:41, Alexander Hansen  
> wrote:
> 
> 
>> On Apr 28, 2015, at 09:36, Jack Howarth  wrote:
>> 
>> Looking at the code, it seem we would have to do this check in sub
>> validate_dpkg_file and use global boolean called
>> skip_flat_namespace_check or such. In validate_dpkg_file, regex check
>> $dpkg_filename against both openmpi-shlibs_*.deb or openmpi_*.deb. If
>> either match, set skip_flat_namespace_check to true
>> and otherwise to false. Then add skip_flat_namespace_check as a
>> conditional in the...
>> 
>> if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {
>> 
>> state that controls the flat namespace checks on each file.
>> 
> 
> As Daniel said, adding a new .info field (if that’s what you mean by global 
> boolean) involves adding on another hack to the .deb control field for 2 
> packages out of more than 1.  For something that end-users never see.  
> 
> It’d be easier just to get Brendan to whitelist the packages for his auto 
> builder.
> -- 
> Alexander Hansen, Ph.D.
> Fink User Liaison
> 

Oh wait, I re-parsed that, so I think I understand better what you’re getting 
at.  And I don’t think it will work as intended, since I believe 
$validate_dpkg_file is run only on actual .debs and not on root directories 
before they get packed.

In principle we could just check individual dylib’s names against a whitelist 
of filename patterns and if they match we can skip the flat_namespace check via 
a ‘next’.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Alexander Hansen]

> On Apr 28, 2015, at 09:36, Jack Howarth  wrote:
> 
> Looking at the code, it seem we would have to do this check in sub
> validate_dpkg_file and use global boolean called
> skip_flat_namespace_check or such. In validate_dpkg_file, regex check
> $dpkg_filename against both openmpi-shlibs_*.deb or openmpi_*.deb. If
> either match, set skip_flat_namespace_check to true
> and otherwise to false. Then add skip_flat_namespace_check as a
> conditional in the...
> 
> if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {
> 
> state that controls the flat namespace checks on each file.
> 

As Daniel said, adding a new .info field (if that’s what you mean by global 
boolean) involves adding on another hack to the .deb control field for 2 
packages out of more than 1.  For something that end-users never see.  

It’d be easier just to get Brendan to whitelist the packages for his auto 
builder.
-- 
Alexander Hansen, Ph.D.
Fink User Liaison


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Jack Howarth]

Looking at the code, it seem we would have to do this check in sub
validate_dpkg_file and use global boolean called
skip_flat_namespace_check or such. In validate_dpkg_file, regex check
$dpkg_filename against both openmpi-shlibs_*.deb or openmpi_*.deb. If
either match, set skip_flat_namespace_check to true
and otherwise to false. Then add skip_flat_namespace_check as a
conditional in the...

if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {

state that controls the flat namespace checks on each file.

On Tue, Apr 28, 2015 at 12:30 PM, Jack Howarth
 wrote:
> Since this issue is so rare (only openmpi and libXt require
> flat_namepace...with the latter being an historical artifact to keep
> motif working), why not check the package name as they are processed
> and if it skip the flat_namespace check if the package name matches
> openmpi-shlibs_*.deb or openmpi_*.deb? Ugly but it will suffice.
>
> On Tue, Apr 28, 2015 at 12:20 PM, Alexander Hansen
>  wrote:
>>
>>> On Apr 28, 2015, at 08:41, Jack Howarth  wrote:
>>>
>>> Are the checks for the shlibs in Validation.pm done for the files from
>>> all packages at once or as sets for each package and/or its
>>> split-offs? If the latter, what about the idea of hard-coding a
>>> blacklist into Validation.pm of packages and/or split-off which should
>>> be skipped?
>>>
>>
>> It’s the latter.  .info file validation is done as a batch, but the .deb 
>> validator works package by package—ideally only the root directories for the 
>> package family currently being built would even be available for validation 
>> during the build operation.
>> --
>> Alexander Hansen, Ph.D.
>> Fink User Liaison
>>

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Jack Howarth]

Since this issue is so rare (only openmpi and libXt require
flat_namepace...with the latter being an historical artifact to keep
motif working), why not check the package name as they are processed
and if it skip the flat_namespace check if the package name matches
openmpi-shlibs_*.deb or openmpi_*.deb? Ugly but it will suffice.

On Tue, Apr 28, 2015 at 12:20 PM, Alexander Hansen
 wrote:
>
>> On Apr 28, 2015, at 08:41, Jack Howarth  wrote:
>>
>> Are the checks for the shlibs in Validation.pm done for the files from
>> all packages at once or as sets for each package and/or its
>> split-offs? If the latter, what about the idea of hard-coding a
>> blacklist into Validation.pm of packages and/or split-off which should
>> be skipped?
>>
>
> It’s the latter.  .info file validation is done as a batch, but the .deb 
> validator works package by package—ideally only the root directories for the 
> package family currently being built would even be available for validation 
> during the build operation.
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Alexander Hansen]

> On Apr 28, 2015, at 08:41, Jack Howarth  wrote:
> 
> Are the checks for the shlibs in Validation.pm done for the files from
> all packages at once or as sets for each package and/or its
> split-offs? If the latter, what about the idea of hard-coding a
> blacklist into Validation.pm of packages and/or split-off which should
> be skipped?
> 

It’s the latter.  .info file validation is done as a batch, but the .deb 
validator works package by package—ideally only the root directories for the 
package family currently being built would even be available for validation 
during the build operation.
-- 
Alexander Hansen, Ph.D.
Fink User Liaison


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Jack Howarth]

Are the checks for the shlibs in Validation.pm done for the files from
all packages at once or as sets for each package and/or its
split-offs? If the latter, what about the idea of hard-coding a
blacklist into Validation.pm of packages and/or split-off which should
be skipped?

On Tue, Apr 28, 2015 at 11:00 AM, Daniel Macks  wrote:
>
>
> On Tue, 28 Apr 2015 07:52:03 -0700, Alexander Hansen
>  wrote:
>
>>
>> On Apr 21, 2015, at 19:31, Daniel Macks  wrote:
>>
>> On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser
>>  wrote:
>>
>> On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote:
>>
>> Summary: GNU libtool effectively assumed that there would be no 10.10, so
>> a bunch of packages inherited conditional logic that treats 10.10 like
>> 10.1. We’ve been patching against this, and put a .deb validator check
>> for flat_namespace builds.
>>
>> Problem: openmpi apparently requires flat_namespace. Other packages
>> might also need it, too, but I don’t happen to know of any offhand.
>>
>> There are a couple of options to address the problem:
>>
>> 1) Add a boolean override field, e.g. BuildFlatNamespace, to the .info
>> and have that turn off the .deb validation check.
>>
>> This seems like a gateway to propagating new fields with very limited
>> usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody,
>> etc) had a significantly wider need. So far BuildFlatNamespace has N=1.
>> Would it make more sense to have a new more general field that can receive
>> a comma separated list of pre-set values, and each value would indicate a
>> action?
>>
>> RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna
>>
>> Could Type: be extended in this manner?
>>
>> 2) Get rid of the .deb validation check and instead apply mandatory tests
>> in the earlier phases. For example, to test at the end of the compile
>> phase fink-package-precedence could be extended also to check for
>> flat_namespace and packages which need flat_namespace wouldn’t use
>> f-p-p; or an additional option flag could be added to f-p-p. We could
>> also check config.status before the compile phase.
>>
>> Would built debs still be validatable (by hand)?
>>
>> If it controls a validator test, it needs to be in the .deb control
>> file, which means we have to tweak dpkg itself to accept a new foreign
>> field. All for an apparently *very* rare special case? No thanks.
>>
>> Support via f-p-p or a new "fink-library-check" (either one controlled
>> by comand-line flags in the CompileScript) or internal to fink itself
>> prior to rolling the .deb (controllable by some .info field) would make
>> it happen in fink runtime and not require .deb/dpkg hackery. As a
>> bonus, it keeps the buggy-library from ever making it into a .deb for
>> anyone rather than lurking and spreading until someone uses -m to catch
>> it.
>>
>> We already have support for a special token in Shlibs entries to
>> control certain binary library features (32/64-bit cross-arch), so a
>> new "Flat" token could be added there. I think it's a per-file idea,
>> not per-package? I dislike doing it via grep of config.status...we want
>> to catch bad results regardless of how they came about, not just the
>> one way we currently see. Likewise, fink-library-check would take a
>> list of specific file(s) to allow to be flat, not just enable/disable
>> the whole mode (and would allow scanning .so not just .dylib). There
>> are some other sanity checks we might want to do on modules and libs
>> (unresolved symbols? list of runtime deps?), this new script would be a
>> home for them all.
>>
>> dan
>>
>> --
>> Daniel Macks
>> dma...@netspace.org
>>
>> Yeah, I’d definitely prefer not to have problematic .debs actually get built.
>>
>> However, since we kind of need to get a release out shortly, and we
>> currently don’t have code in Fink to handle this, I’d like to
>> know whether to turn off the current flat_namespace check in the
>> validator so that openmpi can get added to the binary distribution or
>> just leave it as-is.
>
> Knock it down to a non-fatal (remove $looks_good=0)? That way it can be
> caught by buildworld and maintainers who look closely, but won't
> prohibit.
>
> dan
>
> --
> Daniel Macks
> dma...@netspace.org
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel

---

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Daniel Macks]

On Tue, 28 Apr 2015 07:52:03 -0700, Alexander Hansen 
 wrote:

>
> On Apr 21, 2015, at 19:31, Daniel Macks  wrote:
>
> On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser 
>  wrote:
>
> On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote:
>
> Summary: GNU libtool effectively assumed that there would be no 10.10, so
> a bunch of packages inherited conditional logic that treats 10.10 like
> 10.1. We’ve been patching against this, and put a .deb validator check
> for flat_namespace builds. 
>
> Problem: openmpi apparently requires flat_namespace. Other packages
> might also need it, too, but I don’t happen to know of any offhand. 
>
> There are a couple of options to address the problem:
>
> 1) Add a boolean override field, e.g. BuildFlatNamespace, to the .info
> and have that turn off the .deb validation check. 
>
> This seems like a gateway to propagating new fields with very limited
> usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody,
> etc) had a significantly wider need. So far BuildFlatNamespace has N=1. 
> Would it make more sense to have a new more general field that can receive
> a comma separated list of pre-set values, and each value would indicate a
> action?
>
> RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna
>
> Could Type: be extended in this manner?
>
> 2) Get rid of the .deb validation check and instead apply mandatory tests
> in the earlier phases. For example, to test at the end of the compile
> phase fink-package-precedence could be extended also to check for
> flat_namespace and packages which need flat_namespace wouldn’t use
> f-p-p; or an additional option flag could be added to f-p-p. We could
> also check config.status before the compile phase. 
>
> Would built debs still be validatable (by hand)?
>
> If it controls a validator test, it needs to be in the .deb control 
> file, which means we have to tweak dpkg itself to accept a new foreign 
> field. All for an apparently *very* rare special case? No thanks. 
>
> Support via f-p-p or a new "fink-library-check" (either one controlled 
> by comand-line flags in the CompileScript) or internal to fink itself 
> prior to rolling the .deb (controllable by some .info field) would make 
> it happen in fink runtime and not require .deb/dpkg hackery. As a 
> bonus, it keeps the buggy-library from ever making it into a .deb for 
> anyone rather than lurking and spreading until someone uses -m to catch 
> it. 
>
> We already have support for a special token in Shlibs entries to 
> control certain binary library features (32/64-bit cross-arch), so a 
> new "Flat" token could be added there. I think it's a per-file idea, 
> not per-package? I dislike doing it via grep of config.status...we want 
> to catch bad results regardless of how they came about, not just the 
> one way we currently see. Likewise, fink-library-check would take a 
> list of specific file(s) to allow to be flat, not just enable/disable 
> the whole mode (and would allow scanning .so not just .dylib). There 
> are some other sanity checks we might want to do on modules and libs 
> (unresolved symbols? list of runtime deps?), this new script would be a 
> home for them all. 
>
> dan
>
> --
> Daniel Macks
> dma...@netspace.org
>
> Yeah, I’d definitely prefer not to have problematic .debs actually get built. 
>
> However, since we kind of need to get a release out shortly, and we 
> currently don’t have code in Fink to handle this, I’d like to 
> know whether to turn off the current flat_namespace check in the 
> validator so that openmpi can get added to the binary distribution or 
> just leave it as-is. 

Knock it down to a non-fatal (remove $looks_good=0)? That way it can be 
caught by buildworld and maintainers who look closely, but won't 
prohibit. 

dan

--
Daniel Macks
dma...@netspace.org


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Alexander Hansen]

> On Apr 21, 2015, at 19:31, Daniel Macks  wrote:
> 
> On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser 
> mailto:f...@snaggledworks.com>> wrote:
> 
>> On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote:
>>> Summary: GNU libtool effectively assumed that there would be no 10.10, so
>>> a bunch of packages inherited conditional logic that treats 10.10 like
>>> 10.1. We’ve been patching against this, and put a .deb validator check
>>> for flat_namespace builds. 
>>> 
>>> Problem: openmpi apparently requires flat_namespace. Other packages
>>> might also need it, too, but I don’t happen to know of any offhand. 
>>> 
>>> There are a couple of options to address the problem:
>>> 
>>> 1) Add a boolean override field, e.g. BuildFlatNamespace, to the .info
>>> and have that turn off the .deb validation check. 
>> 
>> This seems like a gateway to propagating new fields with very limited
>> usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody,
>> etc) had a significantly wider need. So far BuildFlatNamespace has N=1. 
>> Would it make more sense to have a new more general field that can receive
>> a comma separated list of pre-set values, and each value would indicate a
>> action?
>> 
>> RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna
>> 
>> Could Type: be extended in this manner?
>> 
>>> 2) Get rid of the .deb validation check and instead apply mandatory tests
>>> in the earlier phases. For example, to test at the end of the compile
>>> phase fink-package-precedence could be extended also to check for
>>> flat_namespace and packages which need flat_namespace wouldn’t use
>>> f-p-p; or an additional option flag could be added to f-p-p. We could
>>> also check config.status before the compile phase. 
>> 
>> Would built debs still be validatable (by hand)?
> 
> If it controls a validator test, it needs to be in the .deb control 
> file, which means we have to tweak dpkg itself to accept a new foreign 
> field. All for an apparently *very* rare special case? No thanks. 
> 
> Support via f-p-p or a new "fink-library-check" (either one controlled 
> by comand-line flags in the CompileScript) or internal to fink itself 
> prior to rolling the .deb (controllable by some .info field) would make 
> it happen in fink runtime and not require .deb/dpkg hackery. As a 
> bonus, it keeps the buggy-library from ever making it into a .deb for 
> anyone rather than lurking and spreading until someone uses -m to catch 
> it. 
> 
> We already have support for a special token in Shlibs entries to 
> control certain binary library features (32/64-bit cross-arch), so a 
> new "Flat" token could be added there. I think it's a per-file idea, 
> not per-package? I dislike doing it via grep of config.status...we want 
> to catch bad results regardless of how they came about, not just the 
> one way we currently see. Likewise, fink-library-check would take a 
> list of specific file(s) to allow to be flat, not just enable/disable 
> the whole mode (and would allow scanning .so not just .dylib). There 
> are some other sanity checks we might want to do on modules and libs 
> (unresolved symbols? list of runtime deps?), this new script would be a 
> home for them all. 
> 
> dan
> 
> --
> Daniel Macks
> dma...@netspace.org 
> 
> 

Yeah, I’d definitely prefer not to have problematic .debs actually get built.

However, since we kind of need to get a release out shortly, and we currently 
don’t have code in Fink to handle this, I’d like to know whether to turn off 
the current flat_namespace check in the validator so that openmpi can get added 
to the binary distribution or just leave it as-is.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Daniel Macks]

On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser 
 wrote:

> On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote:
> > Summary: GNU libtool effectively assumed that there would be no 10.10, so
> > a bunch of packages inherited conditional logic that treats 10.10 like
> > 10.1. We’ve been patching against this, and put a .deb validator check
> > for flat_namespace builds. 
> >
> > Problem: openmpi apparently requires flat_namespace. Other packages
> > might also need it, too, but I don’t happen to know of any offhand. 
> >
> > There are a couple of options to address the problem:
> >
> > 1) Add a boolean override field, e.g. BuildFlatNamespace, to the .info
> > and have that turn off the .deb validation check. 
>
> This seems like a gateway to propagating new fields with very limited
> usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody,
> etc) had a significantly wider need. So far BuildFlatNamespace has N=1. 
> Would it make more sense to have a new more general field that can receive
> a comma separated list of pre-set values, and each value would indicate a
> action?
>
> RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna
>
> Could Type: be extended in this manner?
>
> > 2) Get rid of the .deb validation check and instead apply mandatory tests
> > in the earlier phases. For example, to test at the end of the compile
> > phase fink-package-precedence could be extended also to check for
> > flat_namespace and packages which need flat_namespace wouldn’t use
> > f-p-p; or an additional option flag could be added to f-p-p. We could
> > also check config.status before the compile phase. 
>
> Would built debs still be validatable (by hand)?

If it controls a validator test, it needs to be in the .deb control 
file, which means we have to tweak dpkg itself to accept a new foreign 
field. All for an apparently *very* rare special case? No thanks. 

Support via f-p-p or a new "fink-library-check" (either one controlled 
by comand-line flags in the CompileScript) or internal to fink itself 
prior to rolling the .deb (controllable by some .info field) would make 
it happen in fink runtime and not require .deb/dpkg hackery. As a 
bonus, it keeps the buggy-library from ever making it into a .deb for 
anyone rather than lurking and spreading until someone uses -m to catch 
it. 

We already have support for a special token in Shlibs entries to 
control certain binary library features (32/64-bit cross-arch), so a 
new "Flat" token could be added there. I think it's a per-file idea, 
not per-package? I dislike doing it via grep of config.status...we want 
to catch bad results regardless of how they came about, not just the 
one way we currently see. Likewise, fink-library-check would take a 
list of specific file(s) to allow to be flat, not just enable/disable 
the whole mode (and would allow scanning .so not just .dylib). There 
are some other sanity checks we might want to do on modules and libs 
(unresolved symbols? list of runtime deps?), this new script would be a 
home for them all. 

dan

--
Daniel Macks
dma...@netspace.org


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Alexander Hansen]

> On Apr 21, 2015, at 12:24, Jack Howarth  wrote:
> 
> What about a fink flag that would allow certain stages of validation
> to be skipped. Something like --disable-validation= where it could be
> passed the major stages like deb, etc.
> 

That functionality already exists, sort of.  

-m mode is “fink --validate=on --tests=on” with some extra fatality thrown in.  
Switching to --validate=warn will pop up messages but not cause the build to 
error out.  Though that also loses some of the other changes from warnings to 
fatal errors.  From a maintainer standpoint this may be sufficient.

The problem, of course, being that auto builder scripts _should_ use -m.  And 
adding a flag to fink wouldn’t really help with that because it negates the 
“auto” part.

> On Tue, Apr 21, 2015 at 3:14 PM, Hanspeter Niederstrasser
>  wrote:
>> 
>> On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote:
>>> Summary:  GNU libtool effectively assumed that there would be no 10.10, so
>>> a bunch of packages inherited conditional logic that treats 10.10 like
>>> 10.1.  We’ve been patching against this, and put a .deb validator check
>>> for flat_namespace builds.
>>> 
>>> Problem:  openmpi apparently requires flat_namespace.  Other packages
>>> might also need it, too, but I don’t happen to know of any offhand.
>>> 
>>> There are a couple of options to address the problem:
>>> 
>>> 1)  Add a boolean override field, e.g. BuildFlatNamespace, to the .info
>>> and have that turn off the .deb validation check.
>> 
>> This seems like a gateway to propagating new fields with very limited
>> usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody,
>> etc) had a significantly wider need.  So far BuildFlatNamespace has N=1.
>> Would it make more sense to have a new more general field that can receive
>> a comma separated list of pre-set values, and each value would indicate a
>> action?
>> 
>> RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna
>> 
>> Could Type: be extended in this manner?

There’s probably room for additional magic in Type, yeah.  We’ve got some other 
packages in the distribution that go through hoops to appease the validator, so 
maybe some general override options are in order.

>> 
>>> 2)  Get rid of the .deb validation check and instead apply mandatory tests
>>> in the earlier phases.  For example, to test at the end of the compile
>>> phase fink-package-precedence could be extended also to check for
>>> flat_namespace and packages which need flat_namespace wouldn’t use
>>> f-p-p; or an additional option flag could be added to f-p-p.  We could
>>> also check config.status before the compile phase.
>> 
>> Would built debs still be validatable (by hand)?
>> 
>> Hanspeter
>> 
>> --
>> More agile than a turtle, stronger than a mouse, nobler than a lettuce
>> 
>> 

Sorry, my wording there was a bit broader than I intended. :-)
 
What I meant is that the .deb validator wouldn’t run the check for 
flat_namespace any more.  Instead, we could have packages run a script at the 
end of the configure phase to grep for flat_namespace in e.g. config.status, 
run another script to check the libraries, etc., and give fatal errors if 
problems are detected.  

Ideally, it’d be nice to retain the .deb test, since that lets maintainers know 
that their package needs to be updated and reduces the chance of users having 
misbuilt packages.  

-- 
Alexander Hansen, Ph.D.
Fink User Liaison


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Jack Howarth]

What about a fink flag that would allow certain stages of validation
to be skipped. Something like --disable-validation= where it could be
passed the major stages like deb, etc.

On Tue, Apr 21, 2015 at 3:14 PM, Hanspeter Niederstrasser
 wrote:
>
> On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote:
>> Summary:  GNU libtool effectively assumed that there would be no 10.10, so
>> a bunch of packages inherited conditional logic that treats 10.10 like
>> 10.1.  We’ve been patching against this, and put a .deb validator check
>> for flat_namespace builds.
>>
>> Problem:  openmpi apparently requires flat_namespace.  Other packages
>> might also need it, too, but I don’t happen to know of any offhand.
>>
>> There are a couple of options to address the problem:
>>
>> 1)  Add a boolean override field, e.g. BuildFlatNamespace, to the .info
>> and have that turn off the .deb validation check.
>
> This seems like a gateway to propagating new fields with very limited
> usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody,
> etc) had a significantly wider need.  So far BuildFlatNamespace has N=1.
> Would it make more sense to have a new more general field that can receive
> a comma separated list of pre-set values, and each value would indicate a
> action?
>
> RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna
>
> Could Type: be extended in this manner?
>
>> 2)  Get rid of the .deb validation check and instead apply mandatory tests
>> in the earlier phases.  For example, to test at the end of the compile
>> phase fink-package-precedence could be extended also to check for
>> flat_namespace and packages which need flat_namespace wouldn’t use
>> f-p-p; or an additional option flag could be added to f-p-p.  We could
>> also check config.status before the compile phase.
>
> Would built debs still be validatable (by hand)?
>
> Hanspeter
>
> --
> More agile than a turtle, stronger than a mouse, nobler than a lettuce
>
>
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Handling flat_namespace on 10.10+

[Hanspeter Niederstrasser]

On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote:
> Summary:  GNU libtool effectively assumed that there would be no 10.10, so
> a bunch of packages inherited conditional logic that treats 10.10 like
> 10.1.  We’ve been patching against this, and put a .deb validator check
> for flat_namespace builds.
>
> Problem:  openmpi apparently requires flat_namespace.  Other packages
> might also need it, too, but I don’t happen to know of any offhand.
>
> There are a couple of options to address the problem:
>
> 1)  Add a boolean override field, e.g. BuildFlatNamespace, to the .info
> and have that turn off the .deb validation check.

This seems like a gateway to propagating new fields with very limited
usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody,
etc) had a significantly wider need.  So far BuildFlatNamespace has N=1.
Would it make more sense to have a new more general field that can receive
a comma separated list of pre-set values, and each value would indicate a
action?

RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna

Could Type: be extended in this manner?

> 2)  Get rid of the .deb validation check and instead apply mandatory tests
> in the earlier phases.  For example, to test at the end of the compile
> phase fink-package-precedence could be extended also to check for
> flat_namespace and packages which need flat_namespace wouldn’t use
> f-p-p; or an additional option flag could be added to f-p-p.  We could
> also check config.status before the compile phase.

Would built debs still be validatable (by hand)?

Hanspeter

-- 
More agile than a turtle, stronger than a mouse, nobler than a lettuce


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Handling flat_namespace on 10.10+

[Alexander Hansen]

Summary:  GNU libtool effectively assumed that there would be no 10.10, so a 
bunch of packages inherited conditional logic that treats 10.10 like 10.1.  
We’ve been patching against this, and put a .deb validator check for 
flat_namespace builds.

Problem:  openmpi apparently requires flat_namespace.  Other packages might 
also need it, too, but I don’t happen to know of any offhand.

There are a couple of options to address the problem:

1)  Add a boolean override field, e.g. BuildFlatNamespace, to the .info and 
have that turn off the .deb validation check.
2)  Get rid of the .deb validation check and instead apply mandatory tests in 
the earlier phases.  For example, to test at the end of the compile phase 
fink-package-precedence could be extended also to check for flat_namespace and 
packages which need flat_namespace wouldn’t use f-p-p; or an additional option 
flag could be added to f-p-p.  We could also check config.status before the 
compile phase.

The virtue of option 1 is that by the time the .debs are generated most of the 
weirdness in particular build systems has been smoothed over, so that we’re 
working with libraries and executables.  The downside is that the whole package 
gets built before a problem is found.

Option 2 involves updating f-p-p and generating other helper scripts, or 
perhaps have a check in fink and use a boolean override flag to turn that check 
off—that way the default CompileScript would include the test.

Thoughts?

-- 
Alexander Hansen, Ph.D.
Fink User Liaison


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel