[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/zzuf: ChangeLog zzuf-0.13.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/zzuf: ChangeLog zzuf-0.13.ebuild

[Samuli Suominen]

On 02/26/2010 10:50 PM, Patrick Lauer (patrick) wrote:
> patrick     10/02/26 20:50:29
> 
>   Modified:             ChangeLog
>   Added:                zzuf-0.13.ebuild
>   Log:
>   Bump
>   (Portage version: 2.2_rc63/cvs/Linux x86_64)
> 
> 1.1                  app-forensics/zzuf/zzuf-0.13.ebuild
> 
> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/zzuf/zzuf-0.13.ebuild?rev=1.1&view=markup
> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/zzuf/zzuf-0.13.ebuild?rev=1.1&content-type=text/plain
> 
> Index: zzuf-0.13.ebuild
> ===================================================================
> # Copyright 1999-2010 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: /var/cvsroot/gentoo-x86/app-forensics/zzuf/zzuf-0.13.ebuild,v 1.1 2010/02/26 20:50:28 patrick Exp $
> 

[ .. ]

> src_test() {
> 	if hasq sandbox ${FEATURES}; then
> 		ewarn "zzuf tests don't work correctly when sandbox is enabled,"
> 		ewarn "skipping tests. If you want to run the testsuite, please"
> 		ewarn "disable sandbox for this build."
> 		return
> 	fi

Testing FEATURES from ebuild? You shouldn't do that.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/zzuf: ChangeLog zzuf-0.13.ebuild

[Patrick Lauer]

On 02/26/10 22:02, Samuli Suominen wrote:
> On 02/26/2010 10:50 PM, Patrick Lauer (patrick) wrote:

>> src_test() {
>> 	if hasq sandbox ${FEATURES}; then
>> 		ewarn "zzuf tests don't work correctly when sandbox is enabled,"
>> 		ewarn "skipping tests. If you want to run the testsuite, please"
>> 		ewarn "disable sandbox for this build."
>> 		return
>> 	fi
> 
> Testing FEATURES from ebuild? You shouldn't do that.

I disagree. That's a good way not to fail there, unless someone has a
better idea how to make that work.

And I'd appreciate it if PMS would stop refusing to document FEATURES.
(Double negative? I mean: PMS should document reality)

I won't mind if someone "fixes" that in a way that still has the same
functionality, but I honestly don't see it as a bug, so I'll leave it as
it is.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/zzuf: ChangeLog zzuf-0.13.ebuild

[Samuli Suominen]

On 02/27/2010 12:48 AM, Patrick Lauer wrote:
> On 02/26/10 22:02, Samuli Suominen wrote:
>> On 02/26/2010 10:50 PM, Patrick Lauer (patrick) wrote:
> 
>>> src_test() {
>>> 	if hasq sandbox ${FEATURES}; then
>>> 		ewarn "zzuf tests don't work correctly when sandbox is enabled,"
>>> 		ewarn "skipping tests. If you want to run the testsuite, please"
>>> 		ewarn "disable sandbox for this build."
>>> 		return
>>> 	fi
>>
>> Testing FEATURES from ebuild? You shouldn't do that.
> 
> I disagree. That's a good way not to fail there, unless someone has a
> better idea how to make that work.
> 
> And I'd appreciate it if PMS would stop refusing to document FEATURES.
> (Double negative? I mean: PMS should document reality)
> 
> I won't mind if someone "fixes" that in a way that still has the same
> functionality, but I honestly don't see it as a bug, so I'll leave it as
> it is.
> 

http://bugs.gentoo.org/show_bug.cgi?id=279465
http://bugs.gentoo.org/show_bug.cgi?id=174335

Even this is better,

RESTRICT="test" # Doesn't work with sandbox enabled, see bug 279465

My point is simple: If you don't like the situation / policy, try to
change it, don't go solo with singular ebuild.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/zzuf: ChangeLog zzuf-0.13.ebuild

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On Fri, 26 Feb 2010 23:48:32 +0100
Patrick Lauer <patrick@gentoo.org> wrote:
> And I'd appreciate it if PMS would stop refusing to document FEATURES.
> (Double negative? I mean: PMS should document reality)

PMS does document reality: FEATURES can't be used by ebuilds since its
values aren't reliable. Tests have to be made for the thing that
actually causes the problem, not a variable that indicates that the
user requested but may not have been given the thing that causes the
problem.

But then, we've had this discussion before, and you already know that,
so you're just trying to stir up trouble again.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]