Re: [gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!
On 11/17/08, Peter Volkov [EMAIL PROTECTED] 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 #XX 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!
On Mon, 17 Nov 2008 11:52:25 +0300 Peter Volkov [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
[gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!
Ryan Hill [EMAIL PROTECTED] 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/ pgpfrMDsRCvXs.pgp Description: PGP signature
Re: [gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!
В Вск, 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.
[gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!
Serkan Kaba [EMAIL PROTECTED] 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/ pgpdnNkROqeW7.pgp Description: PGP signature
[gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!
On Sun, 16 Nov 2008 17:24:34 +0100 [EMAIL PROTECTED] (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 signature.asc Description: PGP signature
