Re: [devel] [APT PATCH] test/integration/framework/test-apt-method-http*: use nginx as a forking daemon

["Dmitry V. Levin" <ldv@altlinux.org>]

On Tue, Feb 18, 2020 at 05:47:06PM +0300, Aleksei Nikiforov wrote:
> 18.02.2020 17:28, Dmitry V. Levin пишет:
> > On Tue, Feb 18, 2020 at 05:12:56PM +0300, Ivan Zakharyaschev wrote:
> >> On Tue, 18 Feb 2020, Dmitry V. Levin wrote:
> >>> On Tue, Feb 18, 2020 at 06:39:01AM +0300, Ivan Zakharyaschev wrote:
> >>>> This is needed not to send requests to nginx before it is ready to
> >>>> listen: when the main process forks and exits, nginx is considered to
> >>>> be ready.
> >>>>
> >>>> Without this change, I observed a failure in the http test, but not
> >>>> the https one, probably, because the delay in the https test was
> >>>> larger due to an extra package being built:
> >>>>
> >>>> Run Testcase (22/29) test-apt-method-http
> >>>> Building package: simple-package
> >>>> Test for successful execution of apt-get update …
> >>>> Err http://localhost x86_64 release
> >>>>    Could not connect to localhost:8080 (127.0.0.1). - connect (111 Connection refused)
> >>>>
> >>>> However:
> >>>>
> >>>> Run Testcase (23/29) test-apt-method-https
> >>>> Building package: simple-package
> >>>> Building package: conflicting-package-one
> >>>> Test for successful execution of apt-get update … PASS
> >>>> Test that package(s) are not installed with rpm -q simple-package … PASS
> >>>> Test for successful execution of apt-get install simple-package … PASS
> >>>> Test that package(s) are installed with rpm -q simple-package … PASS
> >>>> Pinning invalid key in apt
> >>>> Test for failure in execution of apt-get update … PASS
> >>>> Test that package(s) are not installed with rpm -q conflicting-package-one … PASS
> >>>> Test for failure in execution of apt-get install conflicting-package-one … PASS
> >>>> Test that package(s) are not installed with rpm -q conflicting-package-one … PASS
> >>>
> >>> Apparently, this fix is insufficient, I experience sporadic failures
> >>> in these nginx-based tests.  Something racy is still there.
> >>
> >> It's a bit difficult for me to help to find out the reason, because I
> >> don't know how to reproduce any other failures than those fixed by my
> >> patch...
> > 
> > It's extremely difficult to go any further while these tests are so flaky.
> > I'm postponing apt patches processing until the test suite is thoroughly fixed.
> 
> Is it extremely difficult to disable 3 tests until better fix is 
> implemented? Or just not pick them up since they are presented in 
> separate commit? I guess it's just an extremely convenient excuse for 
> lazyness.

It's extremely easy to call people names instead of fixing your own bugs.


-- 
ldv