Source: curl Version: 7.60.0-1 Severity: normal Control: affects -1 src:r-cran-curl Forwarded: https://github.com/curl/curl/issues/2674 User: debian...@lists.debian.org Usertags: breaks
Hi Maintainer The issue below, detected by autopkgtests, appears to be related to a known bug in curl. Regards Graham On 20 May 2018 at 20:11, Paul Gevers <elb...@debian.org> wrote: > Dear maintainers, > > [This e-mail is automatically sent. V3.2 (20180518)] > > tl;dr: curl/7.60.0-1 appears to break r-cran-curl/3.2-1 autopkgtest in testing > see: https://ci.debian.net/packages/r/r-cran-curl/testing/amd64/ > and https://qa.debian.org/excuses.php?package=curl > > As recently announced [1] Debian is now running autopkgtests in testing > to check if the migration of a new source package causes regressions. It > does this with the binary packages of the new version of the source > package from unstable. > > With a recent upload of curl the autopkgtest of r-cran-curl > started to fail in testing [2]. This is currently delaying the migration > of curl version 7.60.0-1 [3]. > > This e-mail is meant to trigger prompt direct communication between the > maintainers of the involved packages as one party has insight in what > changed and the other party insight in what is being tested. Please > therefore get in touch with each other with your ideas about what the > causes of the problem might be, proposed patches, etc. A regression in a > reverse dependency can be due to one of the following reasons (of course > not complete): > * new bug in the candidate package (fix the package) > * bug in the test case that only gets triggered due to the update (fix > the reverse dependency, but see below) > * out-of-date reference date in the test case that captures a former bug > in the candidate package (fix the reverse dependency, but see below) > * deprecation of functionality that is used in the reverse dependency > and/or its test case (discussion needed) > * regression due to other packages from unstable that are installed to > fulfill (versioned) Depends (contact maintainers of those). > Triaging tips are being collected on the Debian Wiki [4]. > > Unfortunately sometimes a regression is only intermittent. Ideally this > should be fixed, but it may be OK to just have the autopkgtest retried > (a link is available in the excuses [3]). > > There are cases where it is required to have multiple packages migrate > together to have the test cases pass, e.g. when there was a bug in a > regressing test case of a reverse dependency and that got fixed. In that > case the test cases need to be triggered with both packages from > unstable (reply to this e-mail and/or contact the ci-team [5]) or just > wait until the aging time is over (if the fixed reverse dependency > migrates before that time, the failed test can be retriggered [3]). > > Of course no system is perfect. In case a framework issue is suspected, > don't hesitate to raise the issue via BTS or to the ci-team [5] (reply to > me is also fine for initial cross-check). > > To avoid stepping on peoples toes, this e-mail does not automatically > generate a bug in the BTS, but it is highly recommended to forward this > e-mail there (psuedo-header boilerplate below [6,7]) in case it is > clear which package should solve this regression. > > It can be appropriate to file an RC bug against the depended-on package, > if the regression amounts to an RC bug in the depending package, and to > keep it open while the matter is investigated. That will prevent > migration of an RC regression. > > If the maintainers of the depending package don't have available effort > to fix a problem, it is appropriate for the maintainers of the > depended-on package to consider an NMU of the depending package. Any > such an NMU should take place in accordance with the normal NMU rules. > > Neither of the above steps should be seen as hostile; they are part of > trying to work together to keep Debian in tip-top shape. > > If you find that you are not able to agree between you about the right > next steps, bug severities, etc., please try to find a neutral third > party to help you mediate and/or provide a third opinion. Failing that > your best bet is probably to post to debian-devel. > > [1] https://lists.debian.org/debian-devel-announce/2018/05/msg00001.html > [2] https://ci.debian.net/packages/r/r-cran-curl/testing/amd64/ > [3] https://qa.debian.org/excuses.php?package=curl > [4] https://wiki.debian.org/ContinuousIntegration/TriagingTips > [5] #debci on oftc or debian...@lists.debian.org > [6] curl has an issue > ============ > Source: curl > Version: 7.60.0-1 > Severity: normal or higher > Control: affects -1 src:r-cran-curl > User: debian...@lists.debian.org > Usertags: breaks > ============ > [7] r-cran-curl has an issue > ============ > Source: r-cran-curl > Version: 3.2-1 > Severity: normal or higher > Control: affects -1 src:curl > User: debian...@lists.debian.org > Usertags: needs-update > ============
