- Package:
- src:nghttp2
- Source:
- nghttp2
- Submitter:
- Helmut Grohne
- Date:
- 2023-12-14 10:24:09 UTC
- Severity:
- important
- Tags:
An arch-only build (but not a full build) of nghttp2 seems to reliably
fail at test util_localtime_date:
| Test: util_localtime_date ...FAILED
| 1. util_test.cc:454 - CU_ASSERT_STRING_EQUAL("02/Oct/2001:00:34:56 +1200",util::common_log_date(1001939696).c_str())
| 2. util_test.cc:456 - CU_ASSERT_STRING_EQUAL("2001-10-02T00:34:56.123+12:00",util::iso8601_date(1001939696000LL + 123).c_str())
| 3. util_test.cc:461 - "02/Oct/2001:00:34:56 +1200" == util::format_common_log(common_buf.data(), std::chrono::system_clock::time_point( std::chrono::seconds(1001939696)))
| 4. util_test.cc:468 - "2001-10-02T00:34:56.123+12:00" == util::format_iso8601(iso8601_buf.data(), std::chrono::system_clock::time_point( std::chrono::milliseconds(1001939696123LL)))
...
|
| Run Summary: Type Total Ran Passed Failed Inactive
| suites 1 1 n/a 0 0
| tests 90 90 89 1 0
| asserts 1011 1011 1007 4 n/a
|
| Elapsed time = 0.001 seconds
| FAIL nghttpx-unittest (exit status: 1)
|
| ============================================================================
| Testsuite summary for nghttp2 1.42.0
| ============================================================================
| # TOTAL: 1
| # PASS: 0
| # SKIP: 0
| # XFAIL: 0
| # FAIL: 1
| # XPASS: 0
| # ERROR: 0
| ============================================================================
| See src/test-suite.log
| Please report to t-tujikawa@users.sourceforge.net
| ============================================================================
| make[5]: *** [Makefile:2787: test-suite.log] Error 1
| make[5]: Leaving directory '/<<PKGBUILDDIR>>/src'
| make[4]: *** [Makefile:2895: check-TESTS] Error 2
| make[4]: Leaving directory '/<<PKGBUILDDIR>>/src'
| make[3]: *** [Makefile:2994: check-am] Error 2
| make[3]: Leaving directory '/<<PKGBUILDDIR>>/src'
| make[2]: *** [Makefile:2679: check-recursive] Error 1
| make[2]: Leaving directory '/<<PKGBUILDDIR>>/src'
| make[1]: *** [Makefile:569: check-recursive] Error 1
| make[1]: Leaving directory '/<<PKGBUILDDIR>>'
| dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2
| make: *** [debian/rules:64: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2
Since reproducible only performs full builds, it doesn't see this issue.
Likewise crossqa skips tests and does not see it either. I don't
understand the cause here and just report it. I hope it reproduces
reliably elsewhere as well.
Helmut
Hi Helmut, * Helmut Grohne <helmut@subdivi.de> [210207 19:50]: [..] I'm just passing by, but a local rebuild with `sbuild -d unstable -j8 --no-arch-all` did not show this problem (on amd64). There has to be more to it. Chris
Thank you. I retried it to day (sbuild -d unstable --no-arch-all nghttp2 on amd64) and it failed in the same way. I'm left puzzled what could be different here. One aspect that certainly is not entirely usual is that my chroot lives on a large tmpfs. Could that pose any problems? Any other details I could add to help better understand the issue? Helmut
Hi, There was an upload of nghttp2 yesterday, which built fine on the buildds, so I'm downgrading this bug. Cheers, Ivo
retitle 981600 nghttp2: missing build-depends on tzdata tags 981600 + patch severity 981600 serious thanks Helmut Grohne wrote: > An arch-only build (but not a full build) of nghttp2 seems to reliably > fail at test util_localtime_date: This happens because there is a missing build-dependency on tzdata. Arch-all builds work because python3-sphinx in Build-Depends-Indep depends on tzdata. The official buildds have tzdata in their chroots, but this is really wrong, because tzdata is not build-essential and should therefore not be installed on chroots being used to build packages (see Bug #837060). Trivial patch attached. Please make sure this is also fixed in bullseye as well, as packages in stable must build in stable. Thanks.
fixed 981600 1.51.0-1 thanks Hi. For some reason this is not a problem in bookworm anymore, therefore I'm marking this as fixed in this version. (Could someone double-check?) For bullseye, I propose the attached patch. Note: Some people ask why bother to fix bugs like this in stable when debootstrap installs tzdata by default. Well, I believe the fact that this bug took so much time to be properly diagnosed is an indication that adding a single line to debian/control may save a good amount of debugging time for those who work with minimal chroots (i.e. without packages which are really not build essential). Andreas: I see that you tagged this "sid bookworm". Should it not be really "bullseye" given that it does not happen anymore in bookworm? Thanks.
I can reproduce this doing binary-arch builds in stretch/buster/bullseye (in chroots manually stripped from tzdata and other non-build- essentials). (For binary-indep builds tzdata gets pulled in via B-D-I: sphinx) I cannot reproduce it in bookworm and verified that tzdata does not get pulled in during a binary-arch build, so upstream seems to have modified/dropped this specific test in a release since bullseye. Confirmed. Probably because I couldn't reproduce it in bullseye (in a quick default all+any build) since the subject had lost the important "arch-only" keyword. Fixed now. or migrates to testing. The "fixed version" takes care of reducing the set of affected releases. Andreas PS: Did you talk to the SRM whether they find this fix-worthy on its own in stable or would rather tag it bullseye-ignore, given that it does not happen in a default stable buildd environment. Then the fix could still be bundled with other more important fixes for stable.
El 3/1/23 a las 13:58, Andreas Beckmann escribió: I did not ask SRM about this. In general, they welcome uploads fixing bugs of important severity or higher. While it's true that deboostrap by default creates chroots with tzdata, nobody is forced to use deboostrap, and nobody is forced to accept its default behaviour. My concern here is not about what people would call "the common case", but instead the great level of annoyance which may result when one decides to follow Policy 4.2 and build packages in chroots with only build essential packages (as it happened to Helmut). Therefore, I don't think bullseye-ignore is correct for this, but at the same time, I don't mind if the fix is delayed to a future point release not necessarily the next one. Thanks.