On 04/16/2014 03:39 PM, Lukas Slebodnik wrote:
On (16/04/14 14:38), Lukas Slebodnik wrote:
> On (16/04/14 15:26), Nikolai Kondrashov wrote:
>> On 04/16/2014 03:00 PM, Jakub Hrozek wrote:
>>> On Wed, Apr 16, 2014 at 02:39:06PM +0300, Nikolai Kondrashov wrote:
>>>> Sorry, I felt a bit upset about "This patch is useless". I
understand that my
>>>> patch probably didn't explain enough. However, saying "this is
unclear, please
>>>> elaborate" would have been nicer.
>>>
>>> I think the wording can be attributted to language barrier a bit. I
don't
>>> think anyone tried to embarass you, Nick.
>>>
>>> On the other hand, I agree the wording was harsh. If you were seeing a
>>> problem and you have a patch that fixes the problem for you, then the
>>> patch is mostly certainly not useless, we just need to see if it's the
>>> right way to tackle that problem.
>>
>> Thanks, Jakub.
>>
>>> I'm still not sure I understand where exactly the root cause is, can you
give
>>> me an example of how can I configure sssd to reproduce the breakage locally?
>>
>> My latest reply to Lukas has the answer, but seems to be delayed somewhere.
>>
>> So, use "--with-test-dir=test-dir", don't forget to create the
directory
>> itself. The test will fail then.
>
> In my opinion, directory "${test-dir}" should not be created by configure
> script. We can add test for validation of argument.
> test -d ${TEST_DIR}
>
My fingers were ver fast.
You should fix problem and not symptoms.
Agreed.
However, the problem lies entirely in the test, and I'm trying to solve it.
The test first changes into TEST_DIR, then tries to open TEST_DIR.
This wouldn't work with a relative path such as "test-dir", as there is not
likely to be "test-dir" within "test-dir".
It also tries to create a temporary file in TEST_DIR, while already being in
TEST_DIR. This also doesn't work with "test-dir", for the same reason.
All of the above with TEST_DIR existing at the time of running the test.
Sincerely,
Nick