Bug#1000982: transition: gnustep-base, gnustep-gui
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org We would like the Release Team's permission to carry out a GNUstep transition, namely libgnustep-base1.27 -> 1.28 libgnustep-gui0.28 -> 0.29 As usual, it's better to be done simultaneously (only one round binNMUs for both libraries) since everything that depends on -gui also depends on -base. As always, gnustep-back will need a sourceful upload and should not be binNMUed. I have build-tested all rdeps and no problems were observed, at least on amd64. The auto tracker(s) at release.d.o is/are correct.
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
Ok please send along the patches. Sorry again for all the trouble. Do you know of some way I can check for libtool problems prior to making new releases? I think this is the 3rd time something like this has happened On 12/1/21 7:39 PM, Dirk Eddelbuettel wrote: On 1 December 2021 at 21:41, Sebastian Ramacher wrote: | Indeed, it will need a trip through NEW. So going via experimental would | be appreciated. But, once it passed NEW, you can then immediatly follow | up with the upload to unstable. I will take care of the binNMUs of the | reverse dependencies Done! And big thank you both. We should soon be in better shape with 2.7.1 as libgsl27 ! Patrick: I still have two local patches in the patches. One is one 'gsl-cblas' linkage (and I have forgotten the details, but I can probably dig them up) and a simple manual page edit. We should probably fold the manual page in, and can look into that before the next release. Dirk
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
On 1 December 2021 at 21:41, Sebastian Ramacher wrote: | Indeed, it will need a trip through NEW. So going via experimental would | be appreciated. But, once it passed NEW, you can then immediatly follow | up with the upload to unstable. I will take care of the binNMUs of the | reverse dependencies Done! And big thank you both. We should soon be in better shape with 2.7.1 as libgsl27 ! Patrick: I still have two local patches in the patches. One is one 'gsl-cblas' linkage (and I have forgotten the details, but I can probably dig them up) and a simple manual page edit. We should probably fold the manual page in, and can look into that before the next release. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998057: transition: r-api-bioc-3.14
Hi Graham, On 12/2/21 2:48 AM, Graham Inggs wrote: I've already added hints marking r-bioc-biocparallel/1.28.2-2 urgent and gffread/0.12.1-4 as a bad test, so please do let us know if there are others. Yes, I could spot some more. Please set these to ignore, or Let me know if I should rather workaround to do new uploads with versioned deps. :- * r-bioc-rsamtools -- blocked due to biocparallel in testing * r-bioc-biobase -- blocked due to r-bioc-multiassayexperiment in testing * r-bioc-bluster -- blocked due to r-bioc-scran in testing * r-bioc-genomicranges -- blocked due to r-bioc-multiassayexperiment in testing * r-bioc-iranges -- blocked due to r-bioc-multiassayexperiment in testing * r-bioc-rhdf5lib -- blocked due to r-bioc-rhdf5 in testing * r-bioc-rhdf5filters -- blocked due to r-bioc-rhdf5 in testing * r-bioc-s4vectors -- blocked due to r-bioc-multiassayexperiment in testing * r-bioc-summarizedexperiment -- blocked due to r-bioc-multiassayexperiment in testing Please push urgency for these (just uploaded) :- * r-bioc-scuttle version 1.4.0+dfsg-2 Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Bug#998057: transition: r-api-bioc-3.14
Am Thu, Dec 02, 2021 at 02:30:21AM +0530 schrieb Nilesh Patra: > > Actually, it started issuing a warning with regards to some white space/tab > problem. Something else changed and it is already failing in testing. The warning string comes from libgclib - so the change comes from there. > But yes, it has little to do with any bioconductor package here. Definitely. I wished libgclib would pass new quickly. Kind regards Andreas. -- http://fam-tille.de
Bug#1000628: transition: libotf
Hi On 2021-12-01 11:27:00 +0100, Harshula wrote: > Hi, > > Who triggers the reverse dependency binNMUs? > > I've been following the process as described in: > https://wiki.debian.org/Teams/ReleaseTeam/Transitions I have already scheduled the binNMUs. See https://release.debian.org/transitions/html/auto-libotf.html emacs failed to build on mipsel (#1000744). This bug needs to be resolved in testing for the completion to complete. Cheers > > Thanks, > Harshula > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#998057: transition: r-api-bioc-3.14
Hi Nliesh On Wed, 1 Dec 2021 at 23:00, Nilesh Patra wrote: > But we should make a list of all such packages and ping for Graham/Sebastian > to propagate the hints accordingly. Probably that's what Graham wanted to say > in the first place. I've already added hints marking r-bioc-biocparallel/1.28.2-2 urgent and gffread/0.12.1-4 as a bad test, so please do let us know if there are others. Regards Graham
Bug#1000628: transition: libotf
Hi, Who triggers the reverse dependency binNMUs? I've been following the process as described in: https://wiki.debian.org/Teams/ReleaseTeam/Transitions Thanks, Harshula
Bug#1000973: bullseye-pu: package supysonic/0.6.2+ds-3
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: po...@debian.org [ Reason ] #990148: We are patching the upstream code to use Debian's version of jquery, but it wasn't done properly. Instead of trying to load the file directly from /usr/share/javascript, it should be symlinked in the package's /static directory, like the other JS libs. #990152: We're not symlinking the right bootstrap files. Supysonic wants .min.css files and we're symlinking the non-minimized files. This is not a regression, since it's the first stable release for this package. [ Impact ] These bugs badly break the web interface and severely reduce the usability of the package. [ Tests ] I run this package on a server that's on Bullseye. I've tested the update on this server and it does fix the issues. [ Risks ] The changes are trivial and should bear very low risks. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in stable [x] the issue is verified as fixed in unstable [ Changes ] #990148: * symlinking jquery to /usr/share/supysonic/supysonic/ * using that version in supysonic/supysonic/templates/layout.html #990152: * symlinking bootstrap-theme.min.css and bootstrap.min.css instead of the non minimized versions. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄diff -Nru supysonic-0.6.2+ds/debian/changelog supysonic-0.6.2+ds/debian/changelog --- supysonic-0.6.2+ds/debian/changelog 2021-04-21 11:33:30.0 -0400 +++ supysonic-0.6.2+ds/debian/changelog 2021-11-21 23:45:53.0 -0500 @@ -1,3 +1,11 @@ +supysonic (0.6.2+ds-3+deb11u1) bullseye; urgency=medium + + * d/patches, d/links: Symlink jquery instead of loading it directly. +Closes: #990148. + * d/links: Use the minimized bootstrap CSS files. Closes: #990152. + + -- Louis-Philippe Véronneau Sun, 21 Nov 2021 23:45:53 -0500 + supysonic (0.6.2+ds-3) unstable; urgency=medium * d/tests/control: use sqlite3 instead of sqlite. diff -Nru supysonic-0.6.2+ds/debian/patches/0004_Embedded_JS_Libs.patch supysonic-0.6.2+ds/debian/patches/0004_Embedded_JS_Libs.patch --- supysonic-0.6.2+ds/debian/patches/0004_Embedded_JS_Libs.patch 2020-09-27 20:22:48.0 -0400 +++ supysonic-0.6.2+ds/debian/patches/0004_Embedded_JS_Libs.patch 2021-11-21 23:45:53.0 -0500 @@ -8,7 +8,7 @@ -https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js";> -+ ++ diff -Nru supysonic-0.6.2+ds/debian/supysonic.links supysonic-0.6.2+ds/debian/supysonic.links --- supysonic-0.6.2+ds/debian/supysonic.links 2020-09-27 20:22:48.0 -0400 +++ supysonic-0.6.2+ds/debian/supysonic.links 2021-11-21 23:45:53.0 -0500 @@ -1,10 +1,11 @@ /usr/share/supysonic/supysonic-cli /usr/bin/supysonic-cli /usr/share/supysonic/supysonic-daemon /usr/bin/supysonic-daemon -/usr/share/javascript/bootstrap/css/bootstrap.css /usr/share/supysonic/supysonic/static/css/bootstrap.css +/usr/share/javascript/bootstrap/css/bootstrap.min.css /usr/share/supysonic/supysonic/static/css/bootstrap.min.css /usr/share/javascript/bootstrap/css/bootstrap.css.map /usr/share/supysonic/supysonic/static/css/bootstrap.css.map -/usr/share/javascript/bootstrap/css/bootstrap-theme.css /usr/share/supysonic/supysonic/static/css/bootstrap-theme.css +/usr/share/javascript/bootstrap/css/bootstrap-theme.min.css /usr/share/supysonic/supysonic/static/css/bootstrap-theme.min.css /usr/share/javascript/bootstrap/css/bootstrap-theme.css.map /usr/share/supysonic/supysonic/static/css/bootstrap-theme.css.map /usr/share/javascript/bootstrap/js/bootstrap.min.js /usr/share/supysonic/supysonic/static/js/bootstrap.min.js +/usr/share/javascript/jquery/jquery.min.js /usr/share/supysonic/supysonic/static/js/jquery.min.js /usr/share/fonts-glyphicons/glyphicons-halflings-regular.eot /usr/share/supysonic/supysonic/static/fonts/glyphicons-halflings-regular.eot /usr/share/fonts-glyphicons/glyphicons-halflings-regular.svg /usr/share/supysonic/supysonic/static/fonts/glyphicons-halflings-regular.svg /usr/share/fonts-glyphicons/glyphicons-halflings-regular.ttf /usr/share/supysonic/supysonic/static/fonts/glyphicons-halflings-regular.ttf OpenPGP_signature Description: OpenPGP digital signature
Bug#998057: transition: r-api-bioc-3.14
On 1 December 2021 11:01:12 pm IST, Andreas Tille wrote: >But this is set[3]. If not Salsa-CI should fail. You are testing it on a different version than in testing that's why it passes. If you want to validate, trigger CI on the upload commit for 0.12.1-4 >Moreover, the issue >is not connected at all to any r-bioc-* package since those packages >do not trigger any warning (which is actually issued by libgclib (may >be an upload of this package has triggered any failure - but it remains >unclear why). Actually, it started issuing a warning with regards to some white space/tab problem. Something else changed and it is already failing in testing. But yes, it has little to do with any bioconductor package here. On 1 December 2021 11:04:13 pm IST, Andreas Tille wrote: >But may be if you can work around this with some hinting that is the >easier solution here Yep. That'd be awesome. But we should make a list of all such packages and ping for Graham/Sebastian to propagate the hints accordingly. Probably that's what Graham wanted to say in the first place. Regards, Nilesh
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
On 2021-12-01 09:15:01 -0600, Dirk Eddelbuettel wrote: > > On 1 December 2021 at 09:45, Sebastian Ramacher wrote: > | On 2021-11-30 22:43:11 -0700, Patrick Alken wrote: > | > All, I have uploaded a new GSL release (2.7.1) which I hope fixes the > | > libtool version numbers > > Patrick, > > Big big thank you! (And I missed this email yesterday) > > | Thank you! > | > | Dirk, please go ahead with gsl 2.7.1 in unstable whenever you are ready. > > Sebastian, > > Maybe I am being dense here ... but it should not go first to experimental? > Or because of a new SO major we do not need a transition and just wait for > normal rebuilds? That would be nice indeed. Indeed, it will need a trip through NEW. So going via experimental would be appreciated. But, once it passed NEW, you can then immediatly follow up with the upload to unstable. I will take care of the binNMUs of the reverse dependencies Cheers > > Bit tied up at work but should get to this this evening. > > Dirk > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")
Christoph Biedl wrote...
> About next steps, I would do the upload in the next days. Let me know if
> you prefer other things to happen first or instead.
To avoid this gets lost I've just uploaded http-parser 2.8.1-1+deb10u2.
Updated debiff attached, only editorial changes since the previous mail.
Regards,
Christoph
diff -Nru http-parser-2.8.1/debian/changelog http-parser-2.8.1/debian/changelog
--- http-parser-2.8.1/debian/changelog 2021-06-04 20:59:56.0 +0200
+++ http-parser-2.8.1/debian/changelog 2021-10-31 23:50:09.0 +0100
@@ -1,3 +1,11 @@
+http-parser (2.8.1-1+deb10u2) buster; urgency=medium
+
+ * Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1.
+Many thanks to Hilko Bengen.
+Closes: #996460, #996939, #996997
+
+ -- Christoph Biedl Sun, 31 Oct 2021
23:50:09 +0100
+
http-parser (2.8.1-1+deb10u1) buster; urgency=medium
* Cherry-pick "Support multi-coding Transfer-Encoding".
diff -Nru http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch
http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch
--- http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 1970-01-01
01:00:00.0 +0100
+++ http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 2021-10-31
23:50:09.0 +0100
@@ -0,0 +1,224 @@
+Subject: Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1
+Author: Hilko Bengen
+Date: 2021-10-22
+Bug-Debian:
+https://bugs.debian.org/996460
+https://bugs.debian.org/996939
+https://bugs.debian.org/996997
+Comment: (by the http-parser maintainer)
+
+ # Problem
+
+ The fix for CVE-2019-15605 introduced an ABI break by changing the
+ layout of struct http_parser - a change that was needed to store a
+ ninth bit in the "flags" field. However, this affected offsets of
+ fields declared as public, causing applications to break.
+
+ # Workaround
+
+ To restore the previous layout while still implementing the fix: Steal
+ one bit from the (private) content_length field (the remaining 63
+ are more than enough) to store the newly introduced flag.
+
+ Also rename the related constant as a safeguard against applications
+ that use it (they must not, see below).
+
+ # Possible regressions
+
+ A lot of work was done to avoid damage for well-behaving applications.
+ It seems all applications in Debian built against http-parser fall
+ into that category.
+
+ Applications however that access fields in struct http_parser that are
+ in the section marked "/** PRIVATE **/" may face issues. Such a
+ behaviour is inacceptable anyway.
+
+ If such a mis-behaving application ...
+
+ * was built using an earlier version of http-parser, the code will
+assume content_length is a 64 bit value. Depending on endianess and
+status of the F_TRANSFER_ENCODING bit, things may work. Possibly
+they will not.
+
+ * uses the private F_TRANSFER_ENCODING constant and was built using
+http-parser 2.8.1-1+deb10u1, it will not see the information it
+expects to see.
+Additionally, and re-build will fail. This is by design.
+
+ Again, applications must not access fields declared private, and their
+ authors should not expect pity if they encounter breakage any anything
+ changes there.
+
+ # Acknowledgments
+
+ Thanks a lot to Hilko Bengen for the idea, implementation, a first
+ round of tests and many suggestions.
+
+--- a/http_parser.c
b/http_parser.c
+@@ -25,9 +25,7 @@
+ #include
+ #include
+
+-#ifndef ULLONG_MAX
+-# define ULLONG_MAX ((uint64_t) -1) /* 2^64-1 */
+-#endif
++#define CONTENT_LENGTH_MAX (((uint64_t)-1) >> 1)
+
+ #ifndef MIN
+ # define MIN(a,b) ((a) < (b) ? (a) : (b))
+@@ -724,7 +722,8 @@
+ if (ch == CR || ch == LF)
+ break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+
+ if (ch == 'H') {
+ UPDATE_STATE(s_res_or_resp_H);
+@@ -759,7 +758,8 @@
+ case s_start_res:
+ {
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+
+ switch (ch) {
+ case 'H':
+@@ -923,7 +923,8 @@
+ if (ch == CR || ch == LF)
+ break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+
+ if (UNLIKELY(!IS_ALPHA(ch))) {
+ SET_ERRNO(HPE_INVALID_METHOD);
+@@ -1314,7 +1315,7 @@
+ parser->header_state = h_general;
+ } else if (parser->index == sizeof(TRANSFER_ENCODING)-2) {
+ parser->header_state = h_transfer_encoding;
+-parser->flags |= F_TRANSFER_ENCODING;
++parser->flags2 |= F_TRANSFER_ENCODING2;
+ }
+ break;
+
+@@ -1528,7 +1529,7 @@
+ t += ch - '0';
+
+
Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1
On Wed, 2021-12-01 at 14:16 +0400, Daniel Kahn Gillmor wrote: > On Wed 2021-12-01 09:43:18 +, Adam D. Barratt wrote: > > It looks like you've hit a (fairly) common issue with trying to > > upload > > the same upstream version to multiple suites in a short time. [...] > I can't help but wonder whether there isn't some way to avoid the > need > for a workaround in the backend anyway, though. for example, if the > orig.tar.gz is missing, look in neighboring suites for one with the > matching digest. Where would i look for a bug report on the > infrastructure that would cover this? > This is queued - https://salsa.debian.org/ftp-team/dak/-/tree/master/tools/debianqueued-0.9 - which runs on the upload servers, rather than dak. It doesn't have access to the archive database or filesystem in order to be able to reason about whether files are already available elsewhere. dak, otoh, does have that information, hence things work fine if you only include the orig in the first of your .changes files, or indeed neither if it's already in another suite. If you wanted to try and improve queued, the archive team and the ftp.debian.org pseudo-package are where you'd want to be. Regards, Adam
Bug#998057: transition: r-api-bioc-3.14
Am Wed, Dec 01, 2021 at 06:28:06PM +0100 schrieb Sebastian Ramacher: > On 2021-12-01 22:46:45 +0530, Nilesh Patra wrote: > > Because the version from testing 0.12.1-4 is failing which does not have > > allow-stderr restriction. > > > > The new version 0.12.7 you uploaded has it. The new version is blocked from > > migrating because of libgclib. > > libgclib is further blocked from migrating because of ABI breakage. And > > this change is in NEW. > > > > So we are moving in circles. Why are simple changes so slow so god damn > > difficult to do at times?! > > > > I guess a not very good workaround would be to add an explicit breaks for > > gffread (<< 0.12.1-4~) in r-bioc-gviz that would tell Britney the right > > thing to do. More ideas welcome. > > Let's not do that. As this only produces a warning this won't be an > issue for users. I think this can be solved with the appopriate hint. > > The point of Graham's mail was that r-bioc-biocparallel was not the only > package that would have needed a hint. If you want to speed this up, we > need a full list of packages that need to be urgented or need their > autopkgtest regressions investigated. Well, if its only gffread (despite I have no idea why this test fails on debci while passing for me locally and on Salca CI) we can easily droping all r-bioc-* packages from its test. The test is just checking *all* packages in Debian that are featuring a gff file and just reads those files. Droping r-bioc-* packages leaves a sufficient amount of other files to test ... and the warnings are happening not for a single r-bioc-* package but for other ones. But may be if you can work around this with some hinting that is the easier solution here. Kind regards Andreas. -- http://fam-tille.de
Bug#998057: transition: r-api-bioc-3.14
Hi Sebastian, Am Wed, Dec 01, 2021 at 05:13:24PM +0100 schrieb Sebastian Ramacher: > On 2021-12-01 17:06:00 +0100, Andreas Tille wrote: > > > > > > There's at least one more regression; in gffread, caused by > > > r-bioc-gviz [1]. Please check that each r-bioc* package is ready to > > > migrate. > > > > I absolutely fail to understand why the excuses mechanism is actually > > blaming r-bioc-gviz to be responsible to cause that autopkgtest error. > > I even fail to understand why it ends up in an error while there are > > warnings only. I've re-triggered gffread CI test in Salsa[2] which is > > passing. > > > > Any idea what might be wrong here? > > The tests print warnings on stderr. Output on stderr is considered a > test failure if the allow-stderr restriction is not set. But this is set[3]. If not Salsa-CI should fail. Moreover, the issue is not connected at all to any r-bioc-* package since those packages do not trigger any warning (which is actually issued by libgclib (may be an upload of this package has triggered any failure - but it remains unclear why). Kind regards Andreas. > > > [1] https://qa.debian.org/excuses.php?package=r-bioc-gviz > > [2] https://salsa.debian.org/med-team/gffread/-/jobs/2236429 [3] https://salsa.debian.org/med-team/gffread/-/blob/master/debian/tests/control -- http://fam-tille.de
Bug#998057: transition: r-api-bioc-3.14
On 2021-12-01 22:46:45 +0530, Nilesh Patra wrote: > On 1 December 2021 9:36:00 pm IST, Andreas Tille wrote: > >Hi Graham, > > > >Am Wed, Dec 01, 2021 at 01:33:15PM +0200 schrieb Graham Inggs: > >> On Wed, 1 Dec 2021 at 13:03, Nilesh Patra wrote: > >> > One i386 autopkgtest failure for r-bioc-biocparallel is stalling the > >> > entire migration. Rest stuff looks okay. > >> > >> There's at least one more regression; in gffread, caused by > >> r-bioc-gviz [1]. Please check that each r-bioc* package is ready to > >> migrate. > > > >I absolutely fail to understand why the excuses mechanism is actually > >blaming r-bioc-gviz to be responsible to cause that autopkgtest error. > >I even fail to understand why it ends up in an error while there are > >warnings only. I've re-triggered gffread CI test in Salsa[2] which is > >passing. > > > >Any idea what might be wrong here? > > > >Kind regards > > > > Andreas. > > > >> [1] https://qa.debian.org/excuses.php?package=r-bioc-gviz > >[2] https://salsa.debian.org/med-team/gffread/-/jobs/2236429 > > > > Because the version from testing 0.12.1-4 is failing which does not have > allow-stderr restriction. > > The new version 0.12.7 you uploaded has it. The new version is blocked from > migrating because of libgclib. > libgclib is further blocked from migrating because of ABI breakage. And this > change is in NEW. > > So we are moving in circles. Why are simple changes so slow so god damn > difficult to do at times?! > > I guess a not very good workaround would be to add an explicit breaks for > gffread (<< 0.12.1-4~) in r-bioc-gviz that would tell Britney the right > thing to do. More ideas welcome. Let's not do that. As this only produces a warning this won't be an issue for users. I think this can be solved with the appopriate hint. The point of Graham's mail was that r-bioc-biocparallel was not the only package that would have needed a hint. If you want to speed this up, we need a full list of packages that need to be urgented or need their autopkgtest regressions investigated. Cheers > > Nilesh -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#998057: transition: r-api-bioc-3.14
On 1 December 2021 9:36:00 pm IST, Andreas Tille wrote: >Hi Graham, > >Am Wed, Dec 01, 2021 at 01:33:15PM +0200 schrieb Graham Inggs: >> On Wed, 1 Dec 2021 at 13:03, Nilesh Patra wrote: >> > One i386 autopkgtest failure for r-bioc-biocparallel is stalling the >> > entire migration. Rest stuff looks okay. >> >> There's at least one more regression; in gffread, caused by >> r-bioc-gviz [1]. Please check that each r-bioc* package is ready to >> migrate. > >I absolutely fail to understand why the excuses mechanism is actually >blaming r-bioc-gviz to be responsible to cause that autopkgtest error. >I even fail to understand why it ends up in an error while there are >warnings only. I've re-triggered gffread CI test in Salsa[2] which is >passing. > >Any idea what might be wrong here? > >Kind regards > > Andreas. > >> [1] https://qa.debian.org/excuses.php?package=r-bioc-gviz >[2] https://salsa.debian.org/med-team/gffread/-/jobs/2236429 > Because the version from testing 0.12.1-4 is failing which does not have allow-stderr restriction. The new version 0.12.7 you uploaded has it. The new version is blocked from migrating because of libgclib. libgclib is further blocked from migrating because of ABI breakage. And this change is in NEW. So we are moving in circles. Why are simple changes so slow so god damn difficult to do at times?! I guess a not very good workaround would be to add an explicit breaks for gffread (<< 0.12.1-4~) in r-bioc-gviz that would tell Britney the right thing to do. More ideas welcome. Nilesh
Bug#998057: transition: r-api-bioc-3.14
On 2021-12-01 17:06:00 +0100, Andreas Tille wrote: > Hi Graham, > > Am Wed, Dec 01, 2021 at 01:33:15PM +0200 schrieb Graham Inggs: > > On Wed, 1 Dec 2021 at 13:03, Nilesh Patra wrote: > > > One i386 autopkgtest failure for r-bioc-biocparallel is stalling the > > > entire migration. Rest stuff looks okay. > > > > There's at least one more regression; in gffread, caused by > > r-bioc-gviz [1]. Please check that each r-bioc* package is ready to > > migrate. > > I absolutely fail to understand why the excuses mechanism is actually > blaming r-bioc-gviz to be responsible to cause that autopkgtest error. > I even fail to understand why it ends up in an error while there are > warnings only. I've re-triggered gffread CI test in Salsa[2] which is > passing. > > Any idea what might be wrong here? The tests print warnings on stderr. Output on stderr is considered a test failure if the allow-stderr restriction is not set. Cheers > > Kind regards > >Andreas. > > > [1] https://qa.debian.org/excuses.php?package=r-bioc-gviz > [2] https://salsa.debian.org/med-team/gffread/-/jobs/2236429 > > -- > http://fam-tille.de -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#998057: transition: r-api-bioc-3.14
Hi Graham, Am Wed, Dec 01, 2021 at 01:33:15PM +0200 schrieb Graham Inggs: > On Wed, 1 Dec 2021 at 13:03, Nilesh Patra wrote: > > One i386 autopkgtest failure for r-bioc-biocparallel is stalling the entire > > migration. Rest stuff looks okay. > > There's at least one more regression; in gffread, caused by > r-bioc-gviz [1]. Please check that each r-bioc* package is ready to > migrate. I absolutely fail to understand why the excuses mechanism is actually blaming r-bioc-gviz to be responsible to cause that autopkgtest error. I even fail to understand why it ends up in an error while there are warnings only. I've re-triggered gffread CI test in Salsa[2] which is passing. Any idea what might be wrong here? Kind regards Andreas. > [1] https://qa.debian.org/excuses.php?package=r-bioc-gviz [2] https://salsa.debian.org/med-team/gffread/-/jobs/2236429 -- http://fam-tille.de
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
On 1 December 2021 at 09:45, Sebastian Ramacher wrote: | On 2021-11-30 22:43:11 -0700, Patrick Alken wrote: | > All, I have uploaded a new GSL release (2.7.1) which I hope fixes the | > libtool version numbers Patrick, Big big thank you! (And I missed this email yesterday) | Thank you! | | Dirk, please go ahead with gsl 2.7.1 in unstable whenever you are ready. Sebastian, Maybe I am being dense here ... but it should not go first to experimental? Or because of a new SO major we do not need a transition and just wait for normal rebuilds? That would be nice indeed. Bit tied up at work but should get to this this evening. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998057: transition: r-api-bioc-3.14
Hi, Am Wed, Dec 01, 2021 at 04:29:45PM +0530 schrieb Nilesh Patra: > > One i386 autopkgtest failure for r-bioc-biocparallel is stalling the entire > migration. Its not "only" on i386 if I'm correctly but it randomly happens on different architectures. I've now deactivated the according test so its passing its autopkgtest now (if I'm not totally misleaded). Kind regards Andreas. -- http://fam-tille.de
Processed: tagging 1000511
Processing commands for cont...@bugs.debian.org: > tags 1000511 - moreinfo Bug #1000511 [release.debian.org] bullseye-pu: package debian-edu-config/2.11.56+deb11u2 Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 1000511: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000511 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1
On Wed 2021-12-01 09:43:18 +, Adam D. Barratt wrote: > It looks like you've hit a (fairly) common issue with trying to upload > the same upstream version to multiple suites in a short time. thanks for keeping an eye on this, and giving a quick diagnosis, Adam. > I assume both of your uploads included the .orig.tar.gz and were made > close together. This is exactly right. > At this point your options are either to re-upload the .orig.tar.gz > directly, or dcut and re-upload the complete bullseye upload. i've taken the former approach, uploading directly with sftp. hopefully that'll work :) > In general, either don't include the orig in the later upload, or space > them apart so that you receive the queued confirmation for the first > before uploading the second. (If the orig is already in the archive, as > I assume is the case here, then you don't actually need to include it > in either upload.) Thanks, this is useful guidance for a workaround. I can't help but wonder whether there isn't some way to avoid the need for a workaround in the backend anyway, though. for example, if the orig.tar.gz is missing, look in neighboring suites for one with the matching digest. Where would i look for a bug report on the infrastructure that would cover this? --dkg signature.asc Description: PGP signature
Bug#998057: transition: r-api-bioc-3.14
Hi Nilesh On Wed, 1 Dec 2021 at 13:03, Nilesh Patra wrote: > One i386 autopkgtest failure for r-bioc-biocparallel is stalling the entire > migration. Rest stuff looks okay. There's at least one more regression; in gffread, caused by r-bioc-gviz [1]. Please check that each r-bioc* package is ready to migrate. Regards Graham [1] https://qa.debian.org/excuses.php?package=r-bioc-gviz
Bug#998057: transition: r-api-bioc-3.14
On 24 November 2021 12:37:49 am IST, Sebastian Ramacher wrote: >Control: tags -1 = confirmed > >On 2021-11-23 23:32:46, Nilesh Patra wrote: >> Hi Sebastian, >> >> On Sun, 7 Nov 2021 17:46:56 +0100 Sebastian Ramacher >> wrote: >> > > Hi, >> > > Bioconductor 3.14 was released [1]. >> > > >> > > [1] https://bioconductor.org/news/bioc_3_14_release/ >> > > >> > > Like for previous r-api-bioc transitions, all reverse dependencies >> > > need a manual upgrade to the new upstream releases, they are not >> > > binNMU-able. The Debian R Packages team will do so. >> > > >> > > Please set up a tracker manually, since this is a transition of a >> > > virtual package name. >> > >> > Let's do this one after gsl >> >> Sorry to get on your nerves, but since it has been a little more than two >> weeks since >> you sent this email, is there any update on gsl transition, or is it nearing >> completion or so? >> Can bioc start sometime soon? > >Please go ahead. If the two transitions need to be untangled, I'll >temporarily remove r-bioc-dirichletmultinomial and r-bioc-tfbstools from >testing. Hi Sebastian, One i386 autopkgtest failure for r-bioc-biocparallel is stalling the entire migration. Rest stuff looks okay. For now, could you please set it to ignore? We will deal with it post migration. Regards, Nilesh
Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1
On Wed, 2021-12-01 at 09:43 +, Adam D. Barratt wrote: > On Wed, 2021-12-01 at 13:23 +0400, Daniel Kahn Gillmor wrote: > > On Mon 2021-11-29 20:46:25 +, Adam D. Barratt wrote: > > > Control: tags -1 + confirmed > > > > > > On Wed, 2021-11-10 at 16:09 -0500, Daniel Kahn Gillmor wrote: > > > > Please consider an update to publicsuffix in debian bullseye. > > > > > > > > This package reflects the state of the network, and keeping it > > > > current > > > > is useful for all the packages that depend on it. > > > > > > > > > > Please go ahead. > > > > Thanks, uploaded just now. > > > > It looks like you've hit a (fairly) common issue with trying to > upload > the same upstream version to multiple suites in a short time. > > The buster upload made it fine, but the bullseye upload is stuck in > the > upload queue because: > > Dec 1 09:27:35 publicsuffix_20211109.1735.orig.tar.gz doesn't exist > (ignored for now) > For completeness both uploads now arrived: publicsuffix | 20211109.1735-0+deb10u1 | oldstable-new | source publicsuffix | 20211109.1735-0+deb11u1 | stable-new | source Regards, Adam
Processed: Re: Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1
Processing control commands: > tags -1 - moreinfo Bug #1000785 [release.debian.org] bullseye-pu: package curl/7.74.0-1.3+deb11u1 Removed tag(s) moreinfo. -- 1000785: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000785 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1
Control: tags -1 - moreinfo Hi Adam, On Tue, Nov 30, 2021 at 08:25:57PM +, Adam D. Barratt wrote: > What's the potential impact of the change? Is "curl-config --configure" > consumed by anything, other than human eyeballs? curl-config is mainly meant for machine consumption. It kinda is a predecessor of pkg-config. Preconditions to be affected: * You must perform a build of a software using one of the libcurl*-*-dev packages. * Your build must not use pkg-config (very uncommon), but rather use curl-config. * Your build consumes curl-config --cflags (roughly equivalent to pkg-config --cflags libcurl). As such I think that the number of affected users is fairly small (due to the requirement of not using pkg-config). If all of these are met, then your cflags now lost a flag: -file-prefix-map=$build_path_used_while_building_curl=. This flag should not be used by your build in the first place. Since our buildd build paths are generated randomly, it is very unlikely that any of the files you are building matches this prefix. The flag normally does not have any effect on your build. As such, dropping it normally does not change your build. As such, I think that the risk of breaking something is fairly low. Keep in mind that oldstable lacks this bug (and this flag). If something was seriously broken there, we'd surely have received a bug report by now. Even switching to pkg-config would drop that flag and it really doesn't belong there in the first place. It was injected there by the reproducible builds folks in order to make the curl build unreproducible err I meant reproducible. Whatever. Helmut
Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1
On Wed, 2021-12-01 at 13:23 +0400, Daniel Kahn Gillmor wrote: > On Mon 2021-11-29 20:46:25 +, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Wed, 2021-11-10 at 16:09 -0500, Daniel Kahn Gillmor wrote: > > > Please consider an update to publicsuffix in debian bullseye. > > > > > > This package reflects the state of the network, and keeping it > > > current > > > is useful for all the packages that depend on it. > > > > > > > Please go ahead. > > Thanks, uploaded just now. > It looks like you've hit a (fairly) common issue with trying to upload the same upstream version to multiple suites in a short time. The buster upload made it fine, but the bullseye upload is stuck in the upload queue because: Dec 1 09:27:35 publicsuffix_20211109.1735.orig.tar.gz doesn't exist (ignored for now) I assume both of your uploads included the .orig.tar.gz and were made close together. The effect is that queued processes one of the uploads successfully, and moves all of its files out of the way. It then moves on to the second upload, and discovers that the .orig.tar.gz isn't present, so waits for it to appear (or the upload to be removed after a certain amount of time if it doesn't). At this point your options are either to re-upload the .orig.tar.gz directly, or dcut and re-upload the complete bullseye upload. In general, either don't include the orig in the later upload, or space them apart so that you receive the queued confirmation for the first before uploading the second. (If the orig is already in the archive, as I assume is the case here, then you don't actually need to include it in either upload.) Regards, Adam
Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1
On Mon 2021-11-29 20:46:25 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2021-11-10 at 16:09 -0500, Daniel Kahn Gillmor wrote: >> Please consider an update to publicsuffix in debian bullseye. >> >> This package reflects the state of the network, and keeping it >> current >> is useful for all the packages that depend on it. >> > > Please go ahead. thanks, uploaded just now. --dkg
Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1
On Mon 2021-11-29 20:46:25 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2021-11-10 at 16:09 -0500, Daniel Kahn Gillmor wrote: >> Please consider an update to publicsuffix in debian bullseye. >> >> This package reflects the state of the network, and keeping it >> current >> is useful for all the packages that depend on it. >> > > Please go ahead. Thanks, uploaded just now. --dkg
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
Hi Patrick On 2021-11-30 22:43:11 -0700, Patrick Alken wrote: > All, I have uploaded a new GSL release (2.7.1) which I hope fixes the > libtool version numbers Thank you! Dirk, please go ahead with gsl 2.7.1 in unstable whenever you are ready. Cheers > > On 11/21/21 3:27 PM, Dirk Eddelbuettel wrote: > > Hi Patrick, > > > > Can you please chime in (as you did in the earlier exchanges when Sebastian > > explained to us how to set valus triplet for libtool via configure.ac) ? > > > > On 21 November 2021 at 23:00, Sebastian Ramacher wrote: > > | On 2021-11-09 12:54:44 -0600, Dirk Eddelbuettel wrote: > > | > > > | > On 8 November 2021 at 22:14, Sebastian Ramacher wrote: > > | > | Control: tags -1 moreinfo > > | > | Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-gsl.html > > | > | > > | > | On 2021-10-31 14:29:40 -0500, Dirk Eddelbuettel wrote: > > | > | > > > | > | > Package: release.debian.org > > | > | > Severity: normal > > | > | > User: release.debian@packages.debian.org > > | > | > Usertags: transition > > | > | > > > | > | > GNU GSL 2.7 was release a few months ago, and we now realised (in > > the > > | > | > discussion of #993324 which also included upstream) that the > > upstream libtool > > | > | > instruction were in error by _not_ leading to a new sonumber. This > > was > > | > | > corrected in (source package) gsl upload 2.7-3 to experimental, > > which built > > | > | > well. > > | > | > > | > | What's the status of the fix upstream? Was there any progress? > > Otherwise > > | > | we're gonna repeat that with the next upstream release. > > | > > > | > Those are two distinct issues. Upstream, I think we all agreed in the > > thread > > | > also recorded in the BTS, made an omission in this release where a new > > soname > > | > was needed, but wasn't given. This happens. So now we need a new soname > > | > __because the ABI/API changed__. > > | > > | Yes, the ABI changed and we need a new SONAME. This would ideally be > > | done upstream, though. Even better would be a new release with that > > change. > > > > Yes or no. We could proceed with the patch based on your suggestion. That > > would be "lighterweight" as we would not require upstream work right now. > > | As far as I am aware, the bug report lacks any mail from Patrick which > > > > He did participate earlier. Some of it may have been private mail between > > him > > and myself; I'd have to check. > > > > | would currently mean that we'd have a Debian-specific SONAME. If we go > > | ahead with that, we will end up in on of the following cases: > > | > > | 1. Upstream bumps the SONAME as we discussed it in the bug report. > > | Given the changes in [1], the next release of gsl would then have a > > | SONAME of libgsl.so.26, but with an incompatible ABI compared to what > > we > > | would have in the archive. > > > > I didn't catch that aspect. Yes us moving to libgsl.so.26 by ourself now > > would make it impossible to use that soname later :-/ > > | 2. Upstream bumps the SONAME to a version higher than 26. > > > > (That would be my stylistic preference. If the next GSL is 2.8, why not take > > 28? I may be unaware of other style 'customs' here.) > > | (3. Upstream simply ignores the issue) > > | > > | If 1. happens, we'd be unable to sync up with upstream's SONAME (there's > > | a good reason why we tend to avoid Debian-specific SONAMEs). > > | > > | Patrick, what are your planes? > > > > We're all ears :) > > > > Dirk > > | Best > > | Sebastian > > | > > | [1] > > https://git.savannah.gnu.org/cgit/gsl.git/commit/?id=191bf01a38e590dd0df8aa571accbbd331bfee07 > > | > > | > > > | > That has happened before, and that is why we had transitions in the > > past. > > | > > | > > | > > | > > > | > But not all previous releases had soname changes. I have maintained GSL > > here > > | > for about 20 years and I think this is about the third transition. I > > would > > | > call that defensible. > > | > > > | > The release team does of course have a broader view, and I am always > > keen to > > | > hear your thoughts. > > | > > > | > Cheers, Dirk > > | > > > | > | Cheers > > | > | > > | > | > > > | > | > I would like to ask for a formal transition. As we saw with failing > > tests in > > | > | > dependent packages, binNMUs will not work for all package (but > > possibly > > | > | > "most"). > > | > | > > > | > | > Tentative ben file below. > > | > | > > > | > | > > > - > > | > | > title = "gsl 2.7 transition"; > > | > | > is_affected = .depends ~ /libgsl-dev/; > > | > | > is_good = .depends ~ "libgsl26"; > > | > | > is_bad = .depends ~ "libgsl25"; > > | > | > > > - > > | > | > > > | > | > Let me know if I can help otherwise. > > | > | > > > | > | > Cheers, Dirk > > | > | > > > | > | > > > | > | > -- > > | > | > https://di
