[gentoo-dev] Remember: workarounds don't warrant RESO FIXED!

[gentoo-dev] Remember: workarounds don't warrant RESO FIXED!

[Diego 'Flameeyes' Pettenò]

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


Guys, please remember that if you work something around, you should
_not_ close the bug as RESO FIXED but keep the bug open so that the
issue can be addressed and fixed _properly_. Otherwise we'll end up with
ebuilds full of workarounds without even documentation on why the
workaround is applied!

With workarounds I mean, as examples:

- FEATURES=test failures;
- broken parallel make that requires -j1;
- flags filtering, included -Wl,--no-as-needed appending

This is important because:

a) we want test to work or get fixed upstream;
b) we want users to get parallel build if they request parallel build;
c) we want --as-needed to be used, not ignored.

If the bug is open and comes out on searches and all the rest, then we
have higher chances that someone might _fix_ it, without having to look
to see if there actually is one...

Thanks!

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/


[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] Remember: workarounds don't warrant RESO FIXED!

[Serkan Kaba]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think, resolving as UPSTREAM might be more logical as we can't force
every upstream to fix their *borked* build system and the bug will be
left open forever.

Diego 'Flameeyes' Pettenò yazmış:
> Guys, please remember that if you work something around, you should
> _not_ close the bug as RESO FIXED but keep the bug open so that the
> issue can be addressed and fixed _properly_. Otherwise we'll end up with
> ebuilds full of workarounds without even documentation on why the
> workaround is applied!
> 
> With workarounds I mean, as examples:
> 
> - FEATURES=test failures;
> - broken parallel make that requires -j1;
> - flags filtering, included -Wl,--no-as-needed appending
> 
> This is important because:
> 
> a) we want test to work or get fixed upstream;
> b) we want users to get parallel build if they request parallel build;
> c) we want --as-needed to be used, not ignored.
> 
> If the bug is open and comes out on searches and all the rest, then we
> have higher chances that someone might _fix_ it, without having to look
> to see if there actually is one...
> 
> Thanks!
> 

- --
Sincerely,
Serkan KABA
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkgTssACgkQRh6X64ivZaJq7gCfUSK2fcYQTXeddGfcM0xBLx2S
elQAn3S0hc62XuLrubvpn7kCQhwfiIim
=mvB8
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!

[Diego 'Flameeyes' Pettenò]

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

Serkan Kaba <serkan@gentoo.org> writes:

> I think, resolving as UPSTREAM might be more logical as we can't force
> every upstream to fix their *borked* build system and the bug will be
> left open forever.

If upstream refuses to fix an issue that _is an issue_ we have to fix
it, not work it around forever and ever.

RESO UPSTREAM is good for crashes that are left to upstream, but since
Gentoo si abuilt building, build problems needs to get fixed.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

[gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!

[Ryan Hill]

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

On Sun, 16 Nov 2008 17:24:34 +0100
flameeyes@gmail.com (Diego 'Flameeyes' Pettenò) wrote:

> Guys, please remember that if you work something around, you should
> _not_ close the bug as RESO FIXED but keep the bug open so that the
> issue can be addressed and fixed _properly_. Otherwise we'll end up
> with ebuilds full of workarounds without even documentation on why the
> workaround is applied!
> 
> With workarounds I mean, as examples:

********************************
*                              *
*                              * 
> - FEATURES=test failures;
*                              *
*                              *
********************************

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The next person who closes testsuite failures as invalid or upstream
gets to meet my frozen boot.  If a test fails, fix it.  If it fails
because of portage or Gentoo-specific reasons that can't be fixed then
RESTRICT it.

Everybody is crowing about making src_test enabled by default, yet I
still had 2 out of 3 build failures on my last tinderbox adventure
caused by known, reported, and unfixed testsuite problems.

> - broken parallel make that requires -j1;
> - flags filtering, included -Wl,--no-as-needed appending
> 
> This is important because:
> 
> a) we want test to work or get fixed upstream;
> b) we want users to get parallel build if they request parallel build;
> c) we want --as-needed to be used, not ignored.
> 
> If the bug is open and comes out on searches and all the rest, then we
> have higher chances that someone might _fix_ it, without having to
> look to see if there actually is one...
> 
> Thanks!
> 



-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!

[Peter Volkov]

В Вск, 16/11/2008 в 15:33 -0600, Ryan Hill пишет:
> ********************************
> > - FEATURES=test failures;
> ********************************

And what we are supposed to do if upstream states that tests are not
supposed to be ran on users systems and exists for package development
only? For example one upstream states that the purpose of tests is to
test integrity of the program itself and not program's environment and
he (upstream) is pretty sure that program works as designed...

Also relevant question: some tests require root privileges. What we
should do in such case?

-- 
Peter.

Re: [gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!

[Alec Warner]

On 11/17/08, Peter Volkov <pva@gentoo.org> wrote:
> В Вск, 16/11/2008 в 15:33 -0600, Ryan Hill пишет:
>  > ********************************
>  > > - FEATURES=test failures;
>  > ********************************
>
>  And what we are supposed to do if upstream states that tests are not
>  supposed to be ran on users systems and exists for package development
>  only? For example one upstream states that the purpose of tests is to
>  test integrity of the program itself and not program's environment and
>  he (upstream) is pretty sure that program works as designed...

I assume the upstream developer does not test on the range of hardware
that we have (he certainly doesn't test on mine) and so I think the
tests would remain useful.

>
>  Also relevant question: some tests require root privileges. What we
>  should do in such case?

I think a reasonable course of action would be a multi-pronged approach.

1.  File a bug against portage detailing why the current facilities
(such as RESTRICT) are not meeting your needs.  Bonus points if you
list some ideas that do meet your needs.
2. Add RESTRICT="test" to these packages; with some sort of comment or
identifier as to why

RESTRICT="test" # tests require root access for reason Y, see bug #XXXXXX

3.  If reason Y is silly, attempt to engage upstream to make the tests
run as a normal user.

Note that a bug may already be filed against portage for this; I don't
actually know.

>
>  --
>
> Peter.
>
>
>

[gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!

[Ryan Hill]

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

On Mon, 17 Nov 2008 11:52:25 +0300
Peter Volkov <pva@gentoo.org> wrote:

> В Вск, 16/11/2008 в 15:33 -0600, Ryan Hill пишет:
> > ********************************
> > > - FEATURES=test failures;
> > ********************************
> 
> And what we are supposed to do if upstream states that tests are not
> supposed to be ran on users systems and exists for package development
> only? For example one upstream states that the purpose of tests is to
> test integrity of the program itself and not program's environment and
> he (upstream) is pretty sure that program works as designed...

I think in this case RESTRICTing the tests or running them but not
die-ing on fail would be fine.

> Also relevant question: some tests require root privileges. What we
> should do in such case?

When I asked this previously I was told to check the current user's
permissions before running them.  I haven't had a case where I've had
to though.

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

[gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!

[Diego E. 'Flameeyes' Pettenò]

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

Ryan Hill <dirtyepic@gentoo.org> writes:

>> Also relevant question: some tests require root privileges. What we
>> should do in such case?
>
> When I asked this previously I was told to check the current user's
> permissions before running them.  I haven't had a case where I've had
> to though.

On libarchive there has been some tests requiring root privileges; the
temporary way out was to disable those tests, and the final way out has
been working with upstream so that the testsuite itself detects whether
you have root privileges or not and decides to skip the tests that
cannot be applied.

Just to say.

In general I think it makes sense to be able to run _most_ of the tests
as user, and discard the ones that cannot be run without root privileges
(I expect most software not to require root privileges for the tests,
it's silly to unless you need to work with file permissions or stuff
like that).

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]