Bug#988758: unblock: node-es6-shim/0.35.6+ds-2
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: jpu...@debian.org Severity: normal Please unblock package node-es6-shim [ Reason ] Two days ago an RC bug was reported about broken symlinks in version 0.35.6+ds-1 ; I uploaded 0.35.6+ds-2 to unstable fixing those. [ Impact ] If the unblock isn't granded, the shipped package will have broken symlinks. [ Tests ] "dpkg-deb -c" shows the links point to good locations now. [ Risks ] Only packaging changes, so quite low. [ Checklist ] [*] all changes are documented in the changelog. (only one of them) [*] I reviewed all changes and I approve them (did the change myself) [*] attach debdiff against the package in testing (I have read it carefully, and attached it) [ Other info ] None. unblock node-es6-shim/0.35.6+ds-2 diff -Nru node-es6-shim-0.35.6+ds/debian/changelog node-es6-shim-0.35.6+ds/debian/changelog --- node-es6-shim-0.35.6+ds/debian/changelog 2020-10-20 12:58:25.0 +0200 +++ node-es6-shim-0.35.6+ds/debian/changelog 2021-05-19 08:22:39.0 +0200 @@ -1,3 +1,9 @@ +node-es6-shim (0.35.6+ds-2) unstable; urgency=medium + + * Fix broken symlinks (Closes: #988654). + + -- Julien Puydt Wed, 19 May 2021 08:22:39 +0200 + node-es6-shim (0.35.6+ds-1) unstable; urgency=medium [ Debian Janitor ] diff -Nru node-es6-shim-0.35.6+ds/debian/node-es6-shim.links node-es6-shim-0.35.6+ds/debian/node-es6-shim.links --- node-es6-shim-0.35.6+ds/debian/node-es6-shim.links 2020-10-20 12:58:25.0 +0200 +++ node-es6-shim-0.35.6+ds/debian/node-es6-shim.links 2021-05-19 08:22:39.0 +0200 @@ -1,4 +1,4 @@ -usr/share/javascript/es6-shim/es6-sham.js usr/share/nodejs/es6-shim/es6-sham.js -usr/share/javascript/es6-shim/es6-sham.map usr/share/nodejs/es6-shim/es6-sham.map -usr/share/javascript/es6-shim/es6-shim.js usr/share/nodejs/es6-shim/es6-shim.js -usr/share/javascript/es6-shim/es6-shim.map usr/share/nodejs/es6-shim/es6-shim.map +usr/share/javascript/es6-shim/es6-sham.min.js usr/share/nodejs/es6-shim/es6-sham.js +usr/share/javascript/es6-shim/es6-sham.min.js.map usr/share/nodejs/es6-shim/es6-sham.js.map +usr/share/javascript/es6-shim/es6-shim.min.js usr/share/nodejs/es6-shim/es6-shim.js +usr/share/javascript/es6-shim/es6-shim.min.js.map usr/share/nodejs/es6-shim/es6-shim.js.map
mathcomp-finmap abi-transition
Hi, the Coq-related packages have a habit of breaking their ABI with almost each upload, and until recently that meant broken user configurations: installed packages stopped working because somewhere down the line one of them got a new dress. A few weeks ago, I wrote dh-coq, which made it possible to add more fine-grained Depends/Provides, so that user configurations wouldn't break anymore. All Coq-related packages now to this, so users are safe. Now comes the time of the first transition using this. In testing+unstable we have src:mathcomp-finmap 1.5.1-9 providing libcoq-mathcomp-finmap-urdf7, and I updated its salsa repo to 1.5.2-1, now providing libcoq-mathcomp-finmap-vlib9. When I'll upload it, all packages needing libcoq-mathcomp-finmap will be uninstallable. I have a little script that tells me the following packages will need to be rebuilt when that happens, in that order: mathcomp-finmap mathcomp-analysis mathcomp-multinomials coqeal (the lines are meaningful: same line means parallel build is possible) I think the following ben script is correct: Affected: .build-depends ~ /libcoq-mathcomp-finmap/ Good: .depends ~ /libcoq-mathcomp-finmap-vlib9/ Bad: .depends ~ /libcoq-mathcomp-finmap-urdf7/ It's only partially good because: 1) it only describes what happens from the first line above to the second one, but not the third. 2) the urdf7 vs vlib9 is for amd64 only, so the only universally-good information is the rebuild order. Do you have enough information? If so, just tell me when to upload the new src package version... Cheers, J.Puydt
Bug#1016416: Coq-related packages transition - coq-elpi
Package: release.debian.org Some Coq-related packages need a rebuild: coq-hierarchy-builder mathcomp-algebra-tactics mathcomp-analysis where packages on the same line can be handled in parallel. I can't give a nice ben script because the abi checksum varies with the architecture (see today's mail on debian-devel where I'm trying to find ideas for a better approach). Cheers, J.Puydt
Bug#1016416: Coq-related packages transition - coq-elpi
Hi, Le mardi 02 août 2022 à 21:43 +0200, Sebastian Ramacher a écrit : > On 2022-07-31 13:23:38 +0200, julien.pu...@gmail.com wrote: > > Package: release.debian.org > > > > Some Coq-related packages need a rebuild: > > > > coq-hierarchy-builder > > mathcomp-algebra-tactics mathcomp-analysis > > > > where packages on the same line can be handled in parallel. > > > > I can't give a nice ben script because the abi checksum varies with > > the > > architecture (see today's mail on debian-devel where I'm trying to > > find > > ideas for a better approach). > > From the discussion on -devel, a permanent tracker like the one for > Haskell (https://release.debian.org/transitions/html/haskell.html) > could > help with the rebuilds for coq-* and related packages. Do all > affected > packages depends on some package that we can use as a basis for the > permapermanent tracker? Short answer: no. Longer answer: I have some code to manage the Coq-related packages, which can answer simple questions and might answer complex questions. For example, if I want to update src:coq-elpi, I can run: ./planif_transition.py coq-elpi coq-elpi coq-hierarchy-builder mathcomp-algebra-tactics mathcomp-analysis which tells me what packages I can update and in which order ; some can be parallelized (same line). Since the thread on debian-devel was started, I tried to write another script, aptly named wanna-build, but I'm not sure I got everything right. If I wanted to upload the new upstream of coq-elpi, the plan would be: ./wanna-build.py coq-elpi 1.15.5-1 nmu coq-hierarchy-builder_1.3.0-1 . ANY . -m 'Rebuild due to new coq- elpi 1.15.5-1' dw coq-hierarchy-builder_1.3.0-1 . ANY . -m 'coq-elpi => 1.15.5-1' nmu mathcomp-algebra-tactics_1.0.0-6+b1 . ANY . -m 'Rebuild due to new coq-elpi 1.15.5-1' dw mathcomp-algebra-tactics_1.0.0-6+b1 . ANY . -m 'coq-elpi => 1.15.5- 1' nmu mathcomp-analysis_0.5.2-2 . ANY . -m 'Rebuild due to new coq-elpi 1.15.5-1' dw mathcomp-analysis_0.5.2-2 . ANY . -m 'coq-elpi => 1.15.5-1' dw mathcomp-analysis_0.5.2-2 . ANY . -m 'coq-hierarchy-builder => 1.3.0-1+b1' You might be worried that the planif-transition and wanna-build scripts don't agree on the right time to build mathcomp-algebra-tactics. The reason is that the first looks at the whole dependency graph of Coq- related packages while the second only sees the extracted affected packages dependency graph: both are right, and guarantee a sane building order. Does that look sane? Cheers, J.Puydt
Bug#1016416: Coq-related packages transition - coq-elpi
Le dimanche 07 août 2022 à 21:15 +0200, Sebastian Ramacher a écrit : > On 2022-08-07 11:01:30 +0200, julien.pu...@gmail.com wrote: > > Hi, > > > > Le mardi 02 août 2022 à 21:43 +0200, Sebastian Ramacher a écrit : > > > On 2022-07-31 13:23:38 +0200, julien.pu...@gmail.com wrote: > > > > Package: release.debian.org > > > > > > > > Some Coq-related packages need a rebuild: > > > > > > > > coq-hierarchy-builder > > > > mathcomp-algebra-tactics mathcomp-analysis > > > > > > > > where packages on the same line can be handled in parallel. > > > > > > > > I can't give a nice ben script because the abi checksum varies > > > > with > > > > the > > > > architecture (see today's mail on debian-devel where I'm trying > > > > to > > > > find > > > > ideas for a better approach). > > > > > > From the discussion on -devel, a permanent tracker like the one > > > for > > > Haskell > > > (https://release.debian.org/transitions/html/haskell.html) > > > could > > > help with the rebuilds for coq-* and related packages. Do all > > > affected > > > packages depends on some package that we can use as a basis for > > > the > > > permapermanent tracker? > > > > Short answer: no. > > What about build-dependencies on dh-coq? Is > https://release.debian.org/transitions/html/coq.html missing any > coq-related packages? > The idea to use dh-coq as a marker for Coq-related packages is indeed a good one, and means no list needs to get updated. Your list does contain everything in Debian. [Notice: I also have two packages more, coq-libhyps and coq-relation-algebra -- I have them locally but didn't upload yet because of pending licensing issues.] Here is what my script testing installed packages prints ; it should give an idea of what a full tracker should consider: Hauteur 1 coq... ok Hauteur 2 aac-tactics... ok coq-bignums... ok coq-dpdgraph... ok coq-elpi... ok coq-ext-lib... ok coq-hammer... ok coq-hott... ok coq-libhyps... ok coq-menhirlib... ok coq-record-update... ok coq-reduction-effects... ok coq-stdpp... ok coq-unicoq... ok coq-unimath... ok flocq... ok ott... ok paramcoq... ok ssreflect... ok Hauteur 3 coq-deriving... ok coq-equations... ok coq-gappa... ok coq-hierarchy-builder... ok coq-iris... ok coq-math-classes... ok coq-mtac2... ok coqprime... ok coq-reglang... ok coq-relation-algebra... ok coq-simple-io... ok coquelicot... ok mathcomp-bigenough... ok mathcomp-finmap... ok mathcomp-zify... ok Hauteur 4 coq-corn... ok coq-extructures... ok coq-interval... ok coq-quickchick... ok mathcomp-algebra-tactics... ok mathcomp-analysis... ok mathcomp-multinomials... ok mathcomp-real-closed... ok Hauteur 5 coqeal... ok So checking for dh-coq should give a whole-tree tracker, but does that help with partial updates? Cheers, J.Puydt
Bug#1016923: transition: mathcomp-finmap
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org Hi, I would like to upload src:mathcomp-finmap 1.5.2-1 to unstable ; that means a few other packages will need a recompilation or they'll be uninstallable -- I checked just recompiling in the right order is enough. My experimental wanna-build script for such cases expresses it as: nmu mathcomp-analysis_0.5.2-2 . ANY . -m 'Rebuild due to new mathcomp- finmap 1.5.2-1' dw mathcomp-analysis_0.5.2-2 . ANY . -m 'mathcomp-finmap => 1.5.2-1' nmu mathcomp-multinomials_1.5.5-8 . ANY . -m 'Rebuild due to new mathcomp-finmap 1.5.2-1' dw mathcomp-multinomials_1.5.5-8 . ANY . -m 'mathcomp-finmap => 1.5.2- 1' nmu coqeal_1.1.1-1 . ANY . -m 'Rebuild due to new mathcomp-finmap 1.5.2-1' dw coqeal_1.1.1-1 . ANY . -m 'mathcomp-multinomials => 1.5.5-8+b1' There's also: https://release.debian.org/transitions/html/coq.html which might be helpful. The src:package is signed and ready for dput, just waiting for your ack. Cheers, J.Puydt
Bug#1016923: Updated mathcomp-analysis
Hi, since mathcomp-analysis got upgraded from 0.5.2-2 to 0.5.3-1, the new wanna-build information is : nmu mathcomp-analysis_0.5.3-1 . ANY . -m 'Rebuild due to new mathcomp- finmap 0.5.2-1' dw mathcomp-analysis_0.5.3-1 . ANY . -m 'mathcomp-finmap => 0.5.2-1' nmu mathcomp-multinomials_1.5.5-8 . ANY . -m 'Rebuild due to new mathcomp-finmap 0.5.2-1' dw mathcomp-multinomials_1.5.5-8 . ANY . -m 'mathcomp-finmap => 0.5.2- 1' nmu coqeal_1.1.1-1 . ANY . -m 'Rebuild due to new mathcomp-finmap 0.5.2-1' dw coqeal_1.1.1-1 . ANY . -m 'mathcomp-multinomials => 1.5.5-8+b1' Cheers, J.Puydt
Bug#1019239: transition: coq (41 packages involved)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers Hi, I would like to upload coq 8.16.0+dfsg-1 to unstable ; that also means uploading a number of new versions for other packages: aac-tactics 8.16.0-1 coq-bignums 8.16.0-1 coq-dpdgraph 1.0+8.16-1 coq-elpi 1.15.5-1 coq-reduction-effects 0.1.4-2 coq-hammer 1.3.2+8.16-1 coq-unicoq 1.6-8.16-1 paramcoq 1.1.3+coq8.16-1 coq-hott 8.16-1 coq-equations 1.3-8.16-1 coq-gappa 1.5.2-4 coq-hierarchy-builder 1.3.0-2 coq-mtac2 1.4+8.16-1 coq-simple-io 1.7.0-3 coq-corn 8.16.0-1 coq-quickchick 1.6.4-2 mathcomp-analysis 0.5.3-2 and to just recompile a list of others : all 41 packages of the Coq ecosystem are involved! I would like to dput all new package versions and let the buildd trigger things in order. I checked all compilation would go well on my amd64 box. My experimental wanna-build script gave me something I'll paste below -- as you can guess it's a bit long. Just waiting for a "Go!", J.Puydt PS: nmu coq-deriving_0.1.0-1+b1 . ANY . -m 'Rebuild due to coq=8.16.0+dfsg-1 aac-tactics=8.16.0-1 coq-bignums=8.16.0-1 coq-dpdgraph=1.0+8.16-1 coq-elpi=1.15.5-1 coq-reduction-effects=0.1.4-2 coq-hammer=1.3.2+8.16-1 coq-unicoq=1.6-8.16-1 paramcoq=1.1.3+coq8.16-1 coq-hott=8.16-1 coq-equations=1.3-8.16-1 coq-gappa=1.5.2-4 coq-hierarchy-builder=1.3.0-2 coq-mtac2=1.4+8.16-1 coq-simple-io=1.7.0-3 coq-corn=8.16.0-1 coq-quickchick=1.6.4-2 mathcomp-analysis=0.5.3-2' dw coq-deriving_0.1.0-1+b1 . ANY . -m 'coq => 8.16.0+dfsg-1' nmu coqeal_1.1.1-1+b1 . ANY . -m 'Rebuild due to coq=8.16.0+dfsg-1 aac-tactics=8.16.0-1 coq-bignums=8.16.0-1 coq-dpdgraph=1.0+8.16-1 coq-elpi=1.15.5-1 coq-reduction-effects=0.1.4-2 coq-hammer=1.3.2+8.16-1 coq-unicoq=1.6-8.16-1 paramcoq=1.1.3+coq8.16-1 coq-hott=8.16-1 coq-equations=1.3-8.16-1 coq-gappa=1.5.2-4 coq-hierarchy-builder=1.3.0-2 coq-mtac2=1.4+8.16-1 coq-simple-io=1.7.0-3 coq-corn=8.16.0-1 coq-quickchick=1.6.4-2 mathcomp-analysis=0.5.3-2' dw coqeal_1.1.1-1+b1 . ANY . -m 'coq => 8.16.0+dfsg-1' dw coqeal_1.1.1-1+b1 . ANY . -m 'paramcoq => 1.1.3+coq8.16-1' dw coqeal_1.1.1-1+b1 . ANY . -m 'coq-bignums => 8.16.0-1' nmu coq-ext-lib_0.11.7-1 . ANY . -m 'Rebuild due to coq=8.16.0+dfsg-1 aac-tactics=8.16.0-1 coq-bignums=8.16.0-1 coq-dpdgraph=1.0+8.16-1 coq-elpi=1.15.5-1 coq-reduction-effects=0.1.4-2 coq-hammer=1.3.2+8.16-1 coq-unicoq=1.6-8.16-1 paramcoq=1.1.3+coq8.16-1 coq-hott=8.16-1 coq-equations=1.3-8.16-1 coq-gappa=1.5.2-4 coq-hierarchy-builder=1.3.0-2 coq-mtac2=1.4+8.16-1 coq-simple-io=1.7.0-3 coq-corn=8.16.0-1 coq-quickchick=1.6.4-2 mathcomp-analysis=0.5.3-2' dw coq-ext-lib_0.11.7-1 . ANY . -m 'coq => 8.16.0+dfsg-1' nmu coq-extructures_0.3.1-2 . ANY . -m 'Rebuild due to coq=8.16.0+dfsg-1 aac-tactics=8.16.0-1 coq-bignums=8.16.0-1 coq-dpdgraph=1.0+8.16-1 coq-elpi=1.15.5-1 coq-reduction-effects=0.1.4-2 coq-hammer=1.3.2+8.16-1 coq-unicoq=1.6-8.16-1 paramcoq=1.1.3+coq8.16-1 coq-hott=8.16-1 coq-equations=1.3-8.16-1 coq-gappa=1.5.2-4 coq-hierarchy-builder=1.3.0-2 coq-mtac2=1.4+8.16-1 coq-simple-io=1.7.0-3 coq-corn=8.16.0-1 coq-quickchick=1.6.4-2 mathcomp-analysis=0.5.3-2' dw coq-extructures_0.3.1-2 . ANY . -m 'coq => 8.16.0+dfsg-1' dw coq-extructures_0.3.1-2 . ANY . -m 'coq-deriving => 0.1.0-1+b2' nmu coq-interval_4.5.2-2 . ANY . -m 'Rebuild due to coq=8.16.0+dfsg-1 aac-tactics=8.16.0-1 coq-bignums=8.16.0-1 coq-dpdgraph=1.0+8.16-1 coq-elpi=1.15.5-1 coq-reduction-effects=0.1.4-2 coq-hammer=1.3.2+8.16-1 coq-unicoq=1.6-8.16-1 paramcoq=1.1.3+coq8.16-1 coq-hott=8.16-1 coq-equations=1.3-8.16-1 coq-gappa=1.5.2-4 coq-hierarchy-builder=1.3.0-2 coq-mtac2=1.4+8.16-1 coq-simple-io=1.7.0-3 coq-corn=8.16.0-1 coq-quickchick=1.6.4-2 mathcomp-analysis=0.5.3-2' dw coq-interval_4.5.2-2 . ANY . -m 'coq => 8.16.0+dfsg-1' dw coq-interval_4.5.2-2 . ANY . -m 'coq-bignums => 8.16.0-1' nmu coq-iris_4.0.0-1 . ANY . -m 'Rebuild due to coq=8.16.0+dfsg-1 aac-tactics=8.16.0-1 coq-bignums=8.16.0-1 coq-dpdgraph=1.0+8.16-1 coq-elpi=1.15.5-1 coq-reduction-effects=0.1.4-2 coq-hammer=1.3.2+8.16-1 coq-unicoq=1.6-8.16-1 paramcoq=1.1.3+coq8.16-1 coq-hott=8.16-1 coq-equations=1.3-8.16-1 coq-gappa=1.5.2-4 coq-hierarchy-builder=1.3.0-2 coq-mtac2=1.4+8.16-1 coq-simple-io=1.7.0-3 coq-corn=8.16.0-1 coq-quickchick=1.6.4-2 mathcomp-analysis=0.5.3-2' dw coq-iris_4.0.0-1 . ANY . -m 'coq => 8.16.0+dfsg-1' nmu coq-math-classes_8.15.0-3 . ANY . -m 'Rebuild due to coq=8.16.0+dfsg-1 aac-tactics=8.16.0-1 coq-bignums=8.16.0-1 coq-dpdgraph=1.0+8.16-1 coq-elpi=1.15.5-1 coq-reduction-effects=0.1.4-2 coq-hammer=1.3.2+8.16-1 coq-unicoq=1.6-8.16-1 paramcoq=1.1.3+coq8.16-1 coq-hott=8.16-1 coq-equations=1.3-8.16-1 coq-gappa=1.5.2-4 coq-hierarchy-builder=1.3.0-2 coq-mtac2=1.4+8.16-1 coq-simple-io=1.7.0-3 coq-corn=8.16.0-1 coq-quickchick=1.6.4-2 mathcomp-analysis=0.5.3-2' dw coq-math-classes_8.15.0-3 . ANY . -m 'coq => 8.16.0+dfsg-1' dw coq-math-classes_8.15.0-3 . ANY . -m 'coq
Bug#1019239: transition: coq (41 packages involved)
Le mardi 06 septembre 2022 à 09:41 +0200, Sebastian Ramacher a écrit : > Control: tags -1 confirmed > > Please go ahead and let me know once you're done with all the > uploads. "dput *_source.changes" in the directory where I prepared the new uploads just finished. Thanks, J.Puydt
Bug#1019239: transition: coq (41 packages involved)
Hi Le sam. 10 sept. 2022 à 12:12, Sebastian Ramacher a écrit : > On 2022-09-06 10:56:14 +0200, julien.pu...@gmail.com wrote: > > Le mardi 06 septembre 2022 à 09:41 +0200, Sebastian Ramacher a écrit : > > > Control: tags -1 confirmed > > > > > > Please go ahead and let me know once you're done with all the > > > uploads. > > > > "dput *_source.changes" in the directory where I prepared the new > > uploads just finished. > > The rebuild are now done, but there are some autopkgtest regressions. > They all look like > > https://ci.debian.net/data/autopkgtest/testing/amd64/c/coq-iris/25883605/log.gz > . > Are there some packages that lack the proper dependencies? > H... It shouldn't even be possible to co-install packages not compiled with the same coq, so I'll need to dig a bit to understand why the failure happened this late in the test. Cheers, J.Puydt >
Bug#1019239: transition: coq (41 packages involved)
Hi Le sam. 10 sept. 2022 à 12:12, Sebastian Ramacher a écrit : > > The rebuild are now done, but there are some autopkgtest regressions. > They all look like > > https://ci.debian.net/data/autopkgtest/testing/amd64/c/coq-iris/25883605/log.gz > . > Are there some packages that lack the proper dependencies? > The fact that the coq-iris package isn't a version 4.0.0-1+b1 isn't normal - I guess my wanna-build script was buggy and didn't give every needed nmu line. (I rewrote it since... the new one should be better...) I'll need to check the failing packages - probably monday. Cheers, J.Puydt
Bug#1019239: transition: coq (41 packages involved)
Hi Le sam. 10 sept. 2022 à 14:00, Sebastian Ramacher a écrit : > > coq-stdpp can be installed with any coq version. That will need fixing. > The coq version is a non-issue: the libcoq-stdlib dep should already cover that. I'll look into why it doesn't. Cheers J.Puydt >
Bug#1019239: transition: coq (41 packages involved)
Le samedi 10 septembre 2022 à 12:12 +0200, Sebastian Ramacher a écrit : > > The rebuild are now done, but there are some autopkgtest regressions. > They all look like > https://ci.debian.net/data/autopkgtest/testing/amd64/c/coq-iris/25883605/log.gz > . > Are there some packages that lack the proper dependencies? Yes, there were three bad packages: - coq-menhirlib - coq-stdpp - coq-iris and I already worked on the first two, with the third to follow later today. I think this transition bug can be closed. Cheers, J.Puydt
Bug#1019536: transition: coq-elpi and mathcomp-analysis
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers Hi, There are new versions of two Coq-related packages ; that makes a four- packages transition: nmu coq-hierarchy-builder_1.3.0-2+b2 . ANY . -m 'Rebuild because of upload of coq-elpi=1.15.6-1' dw coq-hierarchy-builder_1.3.0-2+b2 . ANY . -m 'coq-elpi >= 1.15.6-1' dw mathcomp-analysis_0.5.4-1 . ANY . -m 'coq-elpi >= 1.15.6-1' dw mathcomp-analysis_0.5.4-1 . ANY . -m 'coq-hierarchy-builder >= 1.3.0-2+b2' nmu mathcomp-algebra-tactics_1.0.0-6+b3 . ANY . -m 'Rebuild because of upload of coq-elpi=1.15.6-1' dw mathcomp-algebra-tactics_1.0.0-6+b3 . ANY . -m 'coq-elpi >= 1.15.6- 1' I'm ready to upload coq-elpi 1.15.6-1 and mathcomp-analysis 0.5.4-1 when you're ok. Cheers, J.Puydt
Bug#1020564: transition: coq-simple-io
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers Hi, there is a new version of coq-simple-io ; it requires re-building another package: nmu coq-quickchick_1.6.4-2+b1 . ANY . -m 'Rebuild because of upload of coq-simple-io=1.8.0-1' dw coq-quickchick_1.6.4-2+b1 . ANY . -m 'coq-simple-io >= 1.8.0-1' I'm waiting for your approval to upload coq-simple-io 1.8.0-1. Cheers, J.Puydt
Bug#1020564: transition: coq-simple-io
Hi, Le dimanche 25 septembre 2022 à 15:49 +0200, Sebastian Ramacher a écrit : > Control: tags -1 confirmed > > On 2022-09-23 14:36:02 +0200, julien.pu...@gmail.com wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: jpu...@debian.org > > X-Debbugs-Cc: Debian OCaml Maintainers > > > > > > Hi, > > > > there is a new version of coq-simple-io ; it requires re-building > > another package: > > > > nmu coq-quickchick_1.6.4-2+b1 . ANY . -m 'Rebuild because of > > upload of > > coq-simple-io=1.8.0-1' > > dw coq-quickchick_1.6.4-2+b1 . ANY . -m 'coq-simple-io >= 1.8.0-1' > > > > > > I'm waiting for your approval to upload coq-simple-io 1.8.0-1. > > Please go ahead I uploaded coq-simple-io 1.8.0-1 a few days ago already, but it looks like coq-quickchick didn't get rebuilt as I was expecting -- so it's uninstallable and prevents testing migration. What went wrong and what can I do to help ? J.Puydt
Bug#1021090: transition: coq-hierarchy-builder
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers Hi, there is a new version of coq-hierarchy-builder ; it requires rebuilding another package: nmu mathcomp-analysis_0.5.4-1+b2 . ANY . -m 'Rebuild because of upload of coq-hierarchy-builder=1.4.0-1' dw mathcomp-analysis_0.5.4-1+b2 . ANY . -m 'coq-hierarchy-builder >= 1.4.0-1' I'm waiting for your approval to upload coq-hierarchy-builder 1.4.0-1. Cheers, J.Puydt
Bug#1024451: transition: coq-elpi
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers Hi, there is a new version of coq-elpi ; it requires rebuilding other packages: nmu coq-hierarchy-builder_1.4.0-2+b2 . ANY . -m 'Rebuild because of upload of coq-elpi=1.16.0-1' dw coq-hierarchy-builder_1.4.0-2+b2 . ANY . -m 'coq-elpi >= 1.16.0-1' nmu mathcomp-algebra-tactics_1.0.0-8+b2 . ANY . -m 'Rebuild because of upload of coq-elpi=1.16.0-1' dw mathcomp-algebra-tactics_1.0.0-8+b2 . ANY . -m 'coq-elpi >= 1.16.0- 1' nmu mathcomp-analysis_0.5.4-3+b2 . ANY . -m 'Rebuild because of upload of coq-elpi=1.16.0-1 coq-hierarchy-builder=1.4.0-2+b2' dw mathcomp-analysis_0.5.4-3+b2 . ANY . -m 'coq-elpi >= 1.16.0-1' dw mathcomp-analysis_0.5.4-3+b2 . ANY . -m 'coq-hierarchy-builder >= 1.4.0-2+b2' I'm waiting for your approval to upload coq-elpi 1.16.0-1. Cheers, J.Puydt
Bug#1024876: transition: coq 8.16.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers A new upstream version of Coq is out ; it requires rebuilding all depending packages (see below). I'm waiting for the "go!" signal to upload coq 8.16.1-1. Cheers, J.Puydt PS: the upgrade path: nmu aac-tactics_8.16.0-1+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw aac-tactics_8.16.0-1+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-bignums_8.16.0-1+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-bignums_8.16.0-1+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-dpdgraph_1.0+8.16-1+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-dpdgraph_1.0+8.16-1+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-elpi_1.16.0-1+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-elpi_1.16.0-1+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-ext-lib_0.11.7-1+b2 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-ext-lib_0.11.7-1+b2 . ANY . -m 'coq >= 8.16.1-1' nmu coq-hammer_1.3.2+8.16-1+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-hammer_1.3.2+8.16-1+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-hott_8.16-1+b2 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-hott_8.16-1+b2 . ANY . -m 'coq >= 8.16.1-1' nmu coq-libhyps_2.0.6-1+b2 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-libhyps_2.0.6-1+b2 . ANY . -m 'coq >= 8.16.1-1' nmu coq-menhirlib_20220210+ds-3+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-menhirlib_20220210+ds-3+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-record-update_0.3.1-1+b3 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-record-update_0.3.1-1+b3 . ANY . -m 'coq >= 8.16.1-1' nmu coq-reduction-effects_0.1.4-2+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-reduction-effects_0.1.4-2+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-stdpp_1.8.0-2+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-stdpp_1.8.0-2+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-unicoq_1.6-8.16-1+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-unicoq_1.6-8.16-1+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-unimath_20220816-1+b3 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw coq-unimath_20220816-1+b3 . ANY . -m 'coq >= 8.16.1-1' nmu flocq_4.1.0-2+b2 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw flocq_4.1.0-2+b2 . ANY . -m 'coq >= 8.16.1-1' nmu ott_0.32+ds-2+b3 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw ott_0.32+ds-2+b3 . ANY . -m 'coq >= 8.16.1-1' nmu paramcoq_1.1.3+coq8.16-2+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw paramcoq_1.1.3+coq8.16-2+b1 . ANY . -m 'coq >= 8.16.1-1' nmu ssreflect_1.15.0-1+b2 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1' dw ssreflect_1.15.0-1+b2 . ANY . -m 'coq >= 8.16.1-1' nmu coq-deriving_0.1.0-1+b3 . ANY . -m 'Rebuild because of upload of ssreflect=1.15.0-1+b2 coq=8.16.1-1' dw coq-deriving_0.1.0-1+b3 . ANY . -m 'ssreflect >= 1.15.0-1+b2' dw coq-deriving_0.1.0-1+b3 . ANY . -m 'coq >= 8.16.1-1' nmu coq-equations_1.3-8.16-1+b1 . ANY . -m 'Rebuild because of upload of coq=8.16.1-1 coq-hott=8.16-1+b2' dw coq-equations_1.3-8.16-1+b1 . ANY . -m 'coq >= 8.16.1-1' dw coq-equations_1.3-8.16-1+b1 . ANY . -m 'coq-hott >= 8.16-1+b2' nmu coq-gappa_1.5.2-4+b1 . ANY . -m 'Rebuild because of upload of flocq=4.1.0-2+b2 coq=8.16.1-1' dw coq-gappa_1.5.2-4+b1 . ANY . -m 'flocq >= 4.1.0-2+b2' dw coq-gappa_1.5.2-4+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-hierarchy-builder_1.4.0-2+b3 . ANY . -m 'Rebuild because of upload of coq-elpi=1.16.0-1+b1 coq=8.16.1-1' dw coq-hierarchy-builder_1.4.0-2+b3 . ANY . -m 'coq-elpi >= 1.16.0- 1+b1' dw coq-hierarchy-builder_1.4.0-2+b3 . ANY . -m 'coq >= 8.16.1-1' nmu coq-iris_4.0.0-2+b1 . ANY . -m 'Rebuild because of upload of coq- stdpp=1.8.0-2+b1 coq=8.16.1-1' dw coq-iris_4.0.0-2+b1 . ANY . -m 'coq-stdpp >= 1.8.0-2+b1' dw coq-iris_4.0.0-2+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-math-classes_8.15.0-3+b2 . ANY . -m 'Rebuild because of upload of coq-bignums=8.16.0-1+b1 coq=8.16.1-1' dw coq-math-classes_8.15.0-3+b2 . ANY . -m 'coq-bignums >= 8.16.0- 1+b1' dw coq-math-classes_8.15.0-3+b2 . ANY . -m 'coq >= 8.16.1-1' nmu coq-mtac2_1.4+8.16-1+b1 . ANY . -m 'Rebuild because of upload of coq-unicoq=1.6-8.16-1+b1 coq=8.16.1-1' dw coq-mtac2_1.4+8.16-1+b1 . ANY . -m 'coq-unicoq >= 1.6-8.16-1+b1' dw coq-mtac2_1.4+8.16-1+b1 . ANY . -m 'coq >= 8.16.1-1' nmu coq-reglang_1.1.3-1+b3 . ANY . -m 'Rebuild because of upload of ssreflect=1.15.0-1+b2 coq=8.16.1-1' dw coq-reglang_1.1.3-1+b3 . ANY . -m 'ssreflect >= 1.15.0-1+b2' dw coq-reglang_1.1.3-1+b3 . ANY . -m 'coq >= 8.16.1-1' nmu coq-relation-algebra_1.7.8-1+b2 . ANY . -m 'Rebuild because of upload of ssreflect=1.15.0-1+b2 aac-tactics=8.16.0-1+b1 coq=8.16.1-1' dw coq-relation-algebra_1.7.8-1+b2 . ANY . -m 'ssreflect >= 1.15.0- 1+b2
Bug#1025531: transition: elpi 1.16.8-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers A new upstream version of elpi is out ; it requires rebuilding all depending packages: nmu coq-elpi_1.16.0-1+b2 . ANY . -m 'Rebuild because of upload of elpi=1.16.8-1' dw coq-elpi_1.16.0-1+b2 . ANY . -m 'elpi >= 1.16.8-1' nmu coq-hierarchy-builder_1.4.0-2+b4 . ANY . -m 'Rebuild because of upload of coq-elpi=1.16.0-1+b2' dw coq-hierarchy-builder_1.4.0-2+b4 . ANY . -m 'coq-elpi >= 1.16.0- 1+b2' nmu mathcomp-algebra-tactics_1.0.0-8+b4 . ANY . -m 'Rebuild because of upload of coq-elpi=1.16.0-1+b2' dw mathcomp-algebra-tactics_1.0.0-8+b4 . ANY . -m 'coq-elpi >= 1.16.0- 1+b2' nmu mathcomp-analysis_0.5.4-3+b4 . ANY . -m 'Rebuild because of upload of coq-hierarchy-builder=1.4.0-2+b4 coq-elpi=1.16.0-1+b2' dw mathcomp-analysis_0.5.4-3+b4 . ANY . -m 'coq-hierarchy-builder >= 1.4.0-2+b4' dw mathcomp-analysis_0.5.4-3+b4 . ANY . -m 'coq-elpi >= 1.16.0-1+b2' I'm waiting for the "go!" signal to upload elpi 1.16.8-1. Cheers, J.Puydt
Bug#1027057: transition: coq-bignums 8.17.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers A new upstream version of coq-bignums is out ; it requires rebuilding all depending packages: nmu coq-math-classes_8.15.0-3+b3 . ANY . -m 'Rebuild because of upload of coq-bignums=8.17.0-1' dw coq-math-classes_8.15.0-3+b3 . ANY . -m 'coq-bignums >= 8.17.0-1' nmu coqprime_8.15-1+b4 . ANY . -m 'Rebuild because of upload of coq- bignums=8.17.0-1' dw coqprime_8.15-1+b4 . ANY . -m 'coq-bignums >= 8.17.0-1' nmu coq-corn_8.16.0-1+b3 . ANY . -m 'Rebuild because of upload of coq- bignums=8.17.0-1 coq-math-classes=8.15.0-3+b3' dw coq-corn_8.16.0-1+b3 . ANY . -m 'coq-bignums >= 8.17.0-1' dw coq-corn_8.16.0-1+b3 . ANY . -m 'coq-math-classes >= 8.15.0-3+b3' nmu coq-interval_4.6.1-1+b1 . ANY . -m 'Rebuild because of upload of coq-bignums=8.17.0-1' dw coq-interval_4.6.1-1+b1 . ANY . -m 'coq-bignums >= 8.17.0-1' nmu coqeal_1.1.1-2+b2 . ANY . -m 'Rebuild because of upload of coq- bignums=8.17.0-1' dw coqeal_1.1.1-2+b2 . ANY . -m 'coq-bignums >= 8.17.0-1' I'm waiting for the "go!" signal to upload coq-bignums 8.17.0-1 Cheers, J.Puydt
Bug#1027797: transition: aac-tactics 8.17.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers A new upstream version of aac-tactics is out ; it requires rebuilding a depending package: nmu coq-relation-algebra_1.7.8-1+b3 . ANY . -m 'Rebuild because of upload of aac-tactics=8.17.0-1' dw coq-relation-algebra_1.7.8-1+b3 . ANY . -m 'aac-tactics >= 8.17.0- 1' I'm waiting for the "go!" signal to upload aac-tactics 8.17.0-1. Cheers, J.Puydt
Bug#940300: RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream
Package: release.debian.org User: release.debian@packages.debian.org Usertags: rm The newer versions of the minetest game have better than what it provides It's abandoned upstream. This package has no rdeps. I'm the package maintainer (within the Debian Games Team), and I'm proposing to drop it off Debian testing (and unstable, with another bug report). JP
Bug#942106: looking at the remaining "bad" packages in the "add python 3.8" transition
Le samedi 18 janvier 2020 à 02:38 +, peter green a écrit : > I just took a look at the "add python3.8 transition tracker", and > split the remaining "bad" packages into categories. There's another kind of issue ; here is an example : - sagemath builds only for Python 3.7, so some of this subpackages don't load under Python 3.8 : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949023 - which means that for brial, autopkgtest fails : https://ci.debian.net/data/autopkgtest/testing/amd64/b/brial/3988637/log.gz I haven't found the time to investigate things further in sagemath ; I was wondering if I wouldn't disable the Python 3.8 test in brial... not ideal... Cheers, JP
Bug#942106: looking at the remaining "bad" packages in the "add python 3.8" transition
Le dimanche 19 janvier 2020 à 00:54 +, peter green a écrit : > > There's another kind of issue > Yeah, sadly the transition tracker only looks at unstable, so > packages that are fixed in unstable but haven't migrated to testing > for some reason won't show up. > > ; here is an example : > > > > - sagemath builds only for Python 3.7, so some of this subpackages > > don't load under Python 3.8 : > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949023 > > > > - which means that for brial, autopkgtest fails : > > https://ci.debian.net/data/autopkgtest/testing/amd64/b/brial/3988637/log.gz > > Looking at brial, it seems python3-brial should technically have a > dependency on sagemath, but this dependency is omitted for > bootstrapping reasons > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896218 . The test declares a dep on sagemath, but only fails because sagemath doesn't have the necessary /lib/python3/dist- packages/sage/misc/*.cpython*.so. JP
Bug#959224: buster-pu: package scilab/6.0.1-10
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
I received reports (#955694 [main report], #956908 [duplicate]) that scilab
6.1.0+dfsg1-1 stopped working in sid : the move from openjdk 11.0.6 to 11.0.7
broke some of its code ; Gilles Filippini provided a patch and 6.1.0+dfsg1-2
fixed the problem.
Unfortunately, this openjdk also found its way to stable-sec, so broke scilab
6.0.1-10 there (#959034), so I would like to upload a 6.0.1-11+deb10u1 which
would be 6.0.1-10 + adapted patch.
>From tag debian/6.0.1-10, I added a single commit, and checked with sbuild and
a stable+stable-sec that it unbroke things (scilab is run to compile doc, so
getting the package to build is a valid check). I'm putting that commit at the
end of this mail.
The same openjdk will probably also move to stable, so the fixed scilab should
also follow it.
Thanks,
JP
PS: here it is:
commit 55df6269e8ac1a5a4200dbb759c3661bbd1249f2
Author: Julien Puydt
Date: Thu Apr 30 17:22:15 2020 +0200
Add patch from Gilles Filippini to fix library path loading with the recent
openjdk 11.0.7 upload. (Closes: #955694, #959034)
diff --git a/debian/changelog b/debian/changelog
index cf6e4d47f..6578fd506 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+scilab (6.0.1-11+deb10u1) buster; urgency=medium
+
+ * Add patch from Gilles Filippini to fix library path loading
+ with the recent openjdk 11.0.7 upload. (Closes: #955694, #959034)
+
+ -- Julien Puydt Thu, 30 Apr 2020 17:15:32 +0200
+
scilab (6.0.1-10) unstable; urgency=medium
[ Alexis Murzeau ]
diff --git a/debian/patches/addLibraryPath.patch
b/debian/patches/addLibraryPath.patch
new file mode 100644
index 0..d20db1600
--- /dev/null
+++ b/debian/patches/addLibraryPath.patch
@@ -0,0 +1,40 @@
+Description: openjdk 11.0.7 changes how reloading java.library.path works
+ Not it's not possible anymore to force it by setting sys_paths to null
+ The related jdk changeset is:
+ http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21710e014d7f
+Author: Gilles Filippini
+Forwarded: http://bugzilla.scilab.org/show_bug.cgi?id=16423
+
+--- scilab.orig/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.java
scilab/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.java
+@@ -19,7 +19,8 @@
+
/*--*/
+ import java.io.IOException;
+ import java.io.File;
+-import java.lang.reflect.Field;
++import java.lang.reflect.Method;
++import java.lang.reflect.InvocationTargetException;
+
/*--*/
+ /*http://forum.java.sun.com/thread.jspa?threadID=135560&start=15&tstart=0 */
+
/*--*/
+@@ -65,13 +66,13 @@
+ String newLibPath = System.getProperty(JAVALIBRARYPATH) +
File.pathSeparator + p;
+ System.setProperty(JAVALIBRARYPATH, newLibPath);
+ try {
+-Field fieldSysPath =
ClassLoader.class.getDeclaredField("sys_paths");
+-fieldSysPath.setAccessible(true);
+-if (fieldSysPath != null) {
+-fieldSysPath.set(System.class.getClassLoader(), null);
+-}
+-} catch (NoSuchFieldException e) {
+-throw new IOException("Error NoSuchFieldException, could not
add path to " + JAVALIBRARYPATH);
++final Method initLibraryPaths =
ClassLoader.class.getDeclaredMethod("initLibraryPaths");
++initLibraryPaths.setAccessible(true);
++initLibraryPaths.invoke(null);
++} catch (NoSuchMethodException e) {
++throw new IOException("Error NoSuchMethodException, could not
add path to " + JAVALIBRARYPATH);
++} catch (InvocationTargetException e) {
++throw new IOException("Error InvocationTargetException, could
not add path to " + JAVALIBRARYPATH);
+ } catch (IllegalAccessException e) {
+ throw new IOException("Error IllegalAccessException, could
not add path to " + JAVALIBRARYPATH);
+ }
diff --git a/debian/patches/series b/debian/patches/series
index c00c002ff..1979678c0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+addLibraryPath.patch
adddemo.diff
librarypath.diff
jh.diff
Bug#959224: buster-pu: package scilab/6.0.1-10
Le vendredi 01 mai 2020 à 11:21 +0100, Adam D. Barratt a écrit : > Just to confirm, does scilab with this patch still work if used in > conjunction with OpenJDK 11.0.6? (11.0.7 isn't currently available on > a few architectures.) No... it's either with Gilles' patch and it works with 11.0.7 or without and it works with 11.0.6... any other combination doesn't work. I must admit was quite surprised to see openjdk 11.0.7 find its way to stable, since it was known to trigger a FTBFS in scilab. Hope it helps, JP
Bug#959224: buster-pu: package scilab/6.0.1-10
Le vendredi 01 mai 2020 à 11:59 +0100, Adam D. Barratt a écrit : > On Fri, 2020-05-01 at 12:37 +0200, Julien Puydt wrote: > > Le vendredi 01 mai 2020 à 11:21 +0100, Adam D. Barratt a écrit : > > > Just to confirm, does scilab with this patch still work if used > > > in > > > conjunction with OpenJDK 11.0.6? (11.0.7 isn't currently > > > available > > > on a few architectures.) > > > > No... it's either with Gilles' patch and it works with 11.0.7 or > > without and it works with 11.0.6... any other combination doesn't > > work. > > Thanks for the confirmation Gilles Filippini has proposed another patch for scilab, which would make scilab work with both 11.0.6 and 11.0.7 - I still have to test it, but that would definitely be a better solution. JP
Bug#959224: buster-pu: package scilab/6.0.1-10
Le vendredi 01 mai 2020 à 11:59 +0100, Adam D. Barratt a écrit :
> On Fri, 2020-05-01 at 12:37 +0200, Julien Puydt wrote:
> > No... it's either with Gilles' patch and it works with 11.0.7 or
> > without and it works with 11.0.6... any other combination doesn't
> > work.
With Gilles' improved patch, I could build (hence, run) scilab in two
schroots : one is bare stable with openjdk 11.0.6, and the other stable
with security updates with openjdk 11.0.7.
So you'll find at the end the new commit I have against scilab's stable
6.0.1-10 to make it a 6.0.1-11+deb10u11.
Cheers,
JP
PS:
commit a243d928e74f04edbb13686218dff5d6a6a90999
Author: Julien Puydt
Date: Thu Apr 30 17:22:15 2020 +0200
Add patch from Gilles Filippini to fix library path loading with
the recent openjdk 11.0.7 upload. (Closes: #955694, #959034)
diff --git a/debian/changelog b/debian/changelog
index cf6e4d47f..6578fd506 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+scilab (6.0.1-11+deb10u1) buster; urgency=medium
+
+ * Add patch from Gilles Filippini to fix library path loading
+ with the recent openjdk 11.0.7 upload. (Closes: #955694, #959034)
+
+ -- Julien Puydt Thu, 30 Apr 2020 17:15:32 +0200
+
scilab (6.0.1-10) unstable; urgency=medium
[ Alexis Murzeau ]
diff --git a/debian/patches/addLibraryPath.patch
b/debian/patches/addLibraryPath.patch
new file mode 100644
index 0..84abb8df3
--- /dev/null
+++ b/debian/patches/addLibraryPath.patch
@@ -0,0 +1,50 @@
+Description: openjdk 11.0.7 changes how reloading java.library.path
works
+ Now it's not possible anymore to force it by setting sys_paths to
null
+ The related jdk changeset is:
+ http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21710e014d7f
+Author: Gilles Filippini
+Forwarded: http://bugzilla.scilab.org/show_bug.cgi?id=16423
+
+---
scilab.orig/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.jav
a
scilab/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.java
+@@ -19,7 +19,9 @@
+ /*---
---*/
+ import java.io.IOException;
+ import java.io.File;
++import java.lang.reflect.Method;
+ import java.lang.reflect.Field;
++import java.lang.reflect.InvocationTargetException;
+ /*---
---*/
+ /*
http://forum.java.sun.com/thread.jspa?threadID=135560&start=15&tstart=0
*/
+ /*---
---*/
+@@ -64,14 +66,25 @@
+ /* The order matter here... see bug #4022 */
+ String newLibPath = System.getProperty(JAVALIBRARYPATH) +
File.pathSeparator + p;
+ System.setProperty(JAVALIBRARYPATH, newLibPath);
++// First try the new initLibraryPaths method
+ try {
+-Field fieldSysPath =
ClassLoader.class.getDeclaredField("sys_paths");
+-fieldSysPath.setAccessible(true);
+-if (fieldSysPath != null) {
++final Method initLibraryPaths =
ClassLoader.class.getDeclaredMethod("initLibraryPaths");
++initLibraryPaths.setAccessible(true);
++initLibraryPaths.invoke(null);
++} catch (NoSuchMethodException e) {
++// The initLibraryPaths method doesn't exist
++// Fallback setting sys_paths to null
++try {
++Field fieldSysPath =
ClassLoader.class.getDeclaredField("sys_paths");
++fieldSysPath.setAccessible(true);
+ fieldSysPath.set(System.class.getClassLoader(),
null);
++} catch (NoSuchFieldException e1) {
++throw new IOException("Error
NoSuchFieldException, could not add path to " + JAVALIBRARYPATH);
++} catch (IllegalAccessException e1) {
++throw new IOException("Error
IllegalAccessException, could not add path to " + JAVALIBRARYPATH);
+ }
+-} catch (NoSuchFieldException e) {
+-throw new IOException("Error NoSuchFieldException,
could not add path to " + JAVALIBRARYPATH);
++} catch (InvocationTargetException e) {
++throw new IOException("Error
InvocationTargetException, could not add path to " + JAVALIBRARYPATH);
+ } catch (IllegalAccessException e) {
+ throw new IOException("Error IllegalAccessException,
could not add path to " + JAVALIBRARYPATH);
+ }
diff --git a/debian/patches/series b/debian/patches/series
index c00c002ff..1979678c0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+addLibraryPath.patch
adddemo.diff
librarypath.diff
jh.diff
Bug#959224: buster-pu: package scilab/6.0.1-10
Le vendredi 01 mai 2020 à 15:39 +0100, Adam D. Barratt a écrit :
>
> Why -11? I assume the unstable upload will be 6.1.0+dfsg1-3, so this
> is still the first stable update to 6.0.1-10.
I uploaded 6.1.0+dfsg1-3 right now with the improved patch.
Here is the new commit against 6.0.1-10, making it 6.0.1-10+deb10u1.
Cheers,
JP
PS:
diff --git a/debian/changelog b/debian/changelog
index cf6e4d47f..deede011f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+scilab (6.0.1-10+deb10u1) buster; urgency=medium
+
+ * Add patch from Gilles Filippini to fix library path loading
+ with the recent openjdk 11.0.7 upload. (Closes: #955694, #959034)
+
+ -- Julien Puydt Fri, 01 May 2020 16:47:40 +0200
+
scilab (6.0.1-10) unstable; urgency=medium
[ Alexis Murzeau ]
diff --git a/debian/patches/addLibraryPath.patch
b/debian/patches/addLibraryPath.patch
new file mode 100644
index 0..84abb8df3
--- /dev/null
+++ b/debian/patches/addLibraryPath.patch
@@ -0,0 +1,50 @@
+Description: openjdk 11.0.7 changes how reloading java.library.path
works
+ Now it's not possible anymore to force it by setting sys_paths to
null
+ The related jdk changeset is:
+ http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21710e014d7f
+Author: Gilles Filippini
+Forwarded: http://bugzilla.scilab.org/show_bug.cgi?id=16423
+
+---
scilab.orig/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.jav
a
scilab/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.java
+@@ -19,7 +19,9 @@
+ /*---
---*/
+ import java.io.IOException;
+ import java.io.File;
++import java.lang.reflect.Method;
+ import java.lang.reflect.Field;
++import java.lang.reflect.InvocationTargetException;
+ /*---
---*/
+ /*
http://forum.java.sun.com/thread.jspa?threadID=135560&start=15&tstart=0
*/
+ /*---
---*/
+@@ -64,14 +66,25 @@
+ /* The order matter here... see bug #4022 */
+ String newLibPath = System.getProperty(JAVALIBRARYPATH) +
File.pathSeparator + p;
+ System.setProperty(JAVALIBRARYPATH, newLibPath);
++// First try the new initLibraryPaths method
+ try {
+-Field fieldSysPath =
ClassLoader.class.getDeclaredField("sys_paths");
+-fieldSysPath.setAccessible(true);
+-if (fieldSysPath != null) {
++final Method initLibraryPaths =
ClassLoader.class.getDeclaredMethod("initLibraryPaths");
++initLibraryPaths.setAccessible(true);
++initLibraryPaths.invoke(null);
++} catch (NoSuchMethodException e) {
++// The initLibraryPaths method doesn't exist
++// Fallback setting sys_paths to null
++try {
++Field fieldSysPath =
ClassLoader.class.getDeclaredField("sys_paths");
++fieldSysPath.setAccessible(true);
+ fieldSysPath.set(System.class.getClassLoader(),
null);
++} catch (NoSuchFieldException e1) {
++throw new IOException("Error
NoSuchFieldException, could not add path to " + JAVALIBRARYPATH);
++} catch (IllegalAccessException e1) {
++throw new IOException("Error
IllegalAccessException, could not add path to " + JAVALIBRARYPATH);
+ }
+-} catch (NoSuchFieldException e) {
+-throw new IOException("Error NoSuchFieldException,
could not add path to " + JAVALIBRARYPATH);
++} catch (InvocationTargetException e) {
++throw new IOException("Error
InvocationTargetException, could not add path to " + JAVALIBRARYPATH);
+ } catch (IllegalAccessException e) {
+ throw new IOException("Error IllegalAccessException,
could not add path to " + JAVALIBRARYPATH);
+ }
diff --git a/debian/patches/series b/debian/patches/series
index c00c002ff..1979678c0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+addLibraryPath.patch
adddemo.diff
librarypath.diff
jh.diff
Bug#959224: buster-pu: package scilab/6.0.1-10
Le vendredi 01 mai 2020 à 16:38 +0100, Adam D. Barratt a écrit : > Thanks, please feel free to upload that. Done. Thanks, JP
Bug#829371: transition: ntl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition The transition is to a (much) newer version of NTL, going from version 6.2.1 to version 9.9.1. The auto-generated ntl transition page doesn't list flint-arb as a dep, but it probably should since there is a dependency chain ntl -> flint -> flint-arb. I checked that these new ntl packages make it possible to build eclib, flint, linbox, singular and flint-arb on an amd64 debian box, so I don't expect any new problem. There is a FTBFS for flint-arb on armhf, but it was already the case before the transition, so I don't count it as new problem. [Aside: and I'm still trying to sort things out with upstream.] I'll need to find sponsors for the various uploads needed for this transition, but that should be ok. Thanks, Snark on #debian-science Ben file: title = "ntl"; is_affected = .depends ~ "libntl5" | .depends ~ "libntl27"; is_good = .depends ~ "libntl27"; is_bad = .depends ~ "libntl5"; -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#829371: transition: ntl
Hi, On 04/07/2016 14:13, Jonathan Wiltshire wrote: On 2016-07-03 10:30, Jonathan Wiltshire wrote: Control: tag -1 confirmed On 2016-07-02 21:58, Julien Puydt wrote: I checked that these new ntl packages make it possible to build eclib, flint, linbox, singular and flint-arb on an amd64 debian box, so I don't expect any new problem. Please go ahead. Seems to have happened, so rebuilds scheduled. I still follow things on the auto-ntl tracker, so I don't see if anything happens with flint-arb : is it ok ? Snark on #debian-science
Bug#829371: transition: ntl
Hi, On 04/07/2016 14:13, Jonathan Wiltshire wrote: On 2016-07-03 10:30, Jonathan Wiltshire wrote: Control: tag -1 confirmed On 2016-07-02 21:58, Julien Puydt wrote: I checked that these new ntl packages make it possible to build eclib, flint, linbox, singular and flint-arb on an amd64 debian box, so I don't expect any new problem. Please go ahead. Seems to have happened, so rebuilds scheduled. The eclib failure on amd64 is pretty annoying -- I tried on my amd64 box, and got illegal instruction too. Then I compiled libntl27 from apt-get source and installed the obtained libntl27 package, and ran make check again : gone! I don't know what is amiss with the package yet -- and even more worrying: I don't know how I didn't detect the matter when I checked the deps! I'll try to find more about it as soon as possible, Snark on #debian-science
Bug#829371: transition: ntl
Hi, On 06/07/2016 07:46, Julien Puydt wrote: The eclib failure on amd64 is pretty annoying -- I tried on my amd64 box, and got illegal instruction too. Then I compiled libntl27 from apt-get source and installed the obtained libntl27 package, and ran make check again : gone! It turns out compiling upstream ntl 9.9.1 tries to use "-march=native" by default, which is very bad because it gives too cpu-specific packages. Mattia Rizzolo sponsored a 9.9.1-3 packages fixing this problem, so deps failing on amd64 should be re-scheduled. I don't know what is amiss with the package yet -- and even more worrying: I don't know how I didn't detect the matter when I checked the deps! Well, I checked on a box compatible with the build box... and this morning, I checked again on a box not compatible with the build box. That was one of those cases where you have a good chance to get through without seeing something is amiss :-( I'll try to find more about it as soon as possible, Done. Sorry for the inconvenience, Snark on #debian-science
Bug#799245: transition: flint
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debian-scie...@lists.debian.org Hi, I would like to schedule a transition for flint ; what has been done up to now is: (1) the old version 2.4.5-4 is in unstable&testing, and lacks the "Section: libs" which seems to confuse the automatic tools. (2) the new version 2.5.2-2 is in experimental and the ten major arches build ok according to: https://buildd.debian.org/status/package.php?p=flint&suite=experimental (3) the only reverse dep is singular, and I used pbuilder on its current sources and my new package to check a simple rebuild should be enough. The automatically generated tracker for this transition is here, but I'm not sure how good it is: https://release.debian.org/transitions/html/auto-flint.html Before you start working on this transition, you should note it's my first transition so I'm a bit anxious and inexperienced -- and I'm a DM so I'll need to RFS every step. Ben file according to reportbug: title = "flint"; is_affected = .depends ~ "libflint-2.4.5" | .depends ~ "libflint-2.5.2"; is_good = .depends ~ "libflint-2.5.2"; is_bad = .depends ~ "libflint-2.4.5"; Cheers, Snark on #debian-science
Bug#799245: transition: flint
Hi, Le 17/09/2015 10:26, Niels Thykier a écrit : On 2015-09-17 09:44, Julien Puydt wrote: (1) the old version 2.4.5-4 is in unstable&testing, and lacks the "Section: libs" which seems to confuse the automatic tools. Ok, for a small transition like this, it will not be an issue. But for large transitions, this can complicate matters. Well, 2.5.2-2 has it, so that won't complicate anything after that one. Before you start working on this transition, you should note it's my first transition so I'm a bit anxious and inexperienced There is a first for every one. :) Fortunately, it is a rather minor transition, so it will be easy to keep track of. I definitely hope so :-) -- and I'm a DM so I'll need to RFS every step. Ok. If everything goes well, you will only need to upload flint and we will handle the rebuild of singular. Yes. The plan from here. * I will check up on if we can schedule flint now. There are some gcc libraries above flint that have not been checked yet. Good. * After that I will follow up with an "Good ahead" or a "Please wait for X". * Once you get a "Good ahead", please arrange for flint to be uploaded to unstable. This is why I put the debian-science mailing-list in X-Debbugs-CC : I'll follow-up there and hopefully things will go fast. * Notify us once it has built on all architectures in unstable. - Should there be complications (e.g. unexpected build failures), please resolve them (and let us know if it will take a while). I'm pretty confident about the result. * We will then schedule binNMUs for the reverse dependency. Good. * After a few days flint and the rebuilt singular should migrate to testing. * Once libflint-2.4.5 has left testing, the transition is over and we will close this bug. Excellent. Thanks, ~Niels Thanks, Snark on #debian-science
Bug#799245: RFS: Bug#799245: transition: flint
Hi, as seen below, I need a sponsor to upload flint 2.5.2-2 to unstable, so the transition can go forward. Thanks, Snark on #debian-science Le jeudi 17 sept. 2015 à 20:47:02 (+0200), Niels Thykier a écrit : > Control: tags -1 confirmed > > On 2015-09-17 20:16, Julien Puydt wrote: > > Hi, > > > > Le 17/09/2015 10:26, Niels Thykier a écrit : > >> On 2015-09-17 09:44, Julien Puydt wrote: > >>> > >>> (1) the old version 2.4.5-4 is in unstable&testing, and lacks the > >>> "Section: libs" which seems to confuse the automatic tools. > >> > >> Ok, for a small transition like this, it will not be an issue. But for > >> large transitions, this can complicate matters. > > > > Well, 2.5.2-2 has it, so that won't complicate anything after that one. > > > > Sounds good. :) > > >[...] > >> The plan from here. > >> > >> * I will check up on if we can schedule flint now. There are some > >> gcc libraries above flint that have not been checked yet. > > > > [...] > > > > > I believe flint is ready to go, please arrange for the upload to > unstable. :) > > Thanks, > ~Niels > >
Bug#799245: Buildd on unstable: ok
Hi, the new flint is now built on the 10 main arches without an hiccup: https://buildd.debian.org/status/package.php?p=flint So the next step should be a binNMU on singular. Thanks, Snark on #debian-science
Bug#799245: Failure on powerpc
Hi, I notice that the buildd on powerpc failed, but it's an old error: https://buildd.debian.org/status/fetch.php?pkg=singular&arch=powerpc&ver=4.0.1p2%2Bds-1&stamp=1438021079 so that's unrelated to this transition. Snark on #debian-science
Bug#857251: unblock: acorn/4.0.4-2
Package: release.debian.org Severity: important User: release.debian@packages.debian.org Usertags: unblock Please unblock package acorn, to fix bug #850506 ; in summary: the 4.0.4-1 package FTBFS on some computers (and not on others) ; this new 4.0.4-2 has a trivial fix. You'll find the very short debdiff in post scriptum. Thanks, unblock acorn/4.0.4-2 PS: debdiff between 4.0.4-1 and 4.0.4-2: diff -Nru acorn-4.0.4/debian/changelog acorn-4.0.4/debian/changelog --- acorn-4.0.4/debian/changelog2017-01-11 10:42:32.0 +0100 +++ acorn-4.0.4/debian/changelog2017-03-09 07:17:56.0 +0100 @@ -1,3 +1,9 @@ +acorn (4.0.4-2) unstable; urgency=medium + + * Add explicit rule to force compilation ordering (Closes: #850506) + + -- Julien Puydt Thu, 09 Mar 2017 07:17:56 +0100 + acorn (4.0.4-1) unstable; urgency=medium * New upstream release. diff -Nru acorn-4.0.4/debian/rules acorn-4.0.4/debian/rules --- acorn-4.0.4/debian/rules2017-01-11 10:42:32.0 +0100 +++ acorn-4.0.4/debian/rules2017-03-09 07:17:56.0 +0100 @@ -32,6 +32,8 @@ mkdir -p dist/walk ln -s dist/index.js acorn.js +dist/bin/acorn.js: dist/index.js + %.js: $(COMPILE_MODULES) $(subst dist, src, $@) > $@
Bug#1073983: transition: ocaml
Hi, Le jeudi 15 août 2024 à 21:52 +0200, Paul Gevers a écrit : > > On 13-08-2024 08:03, Stéphane Glondu wrote: > > Howevever, many of them are related to the fact that i386 > > and armhf are no longer native (ocaml 5 dropped support for native > > compilation on 32-bit architectures), hence the corresponding > > uninstallability or autopkgtest issues for coq-related packages are > > irrelevant. Is britney smart enough to cope with this? > > If the excuses report an autopkgtest failure, britney2 didn't do what > you were hoping. ocaml builds on all architectures, so how should I > understand your statement? Are these non-installability and > autopkgtest > issues all for source packages that build arch:all binaries? Than > that > needs a hint from our side. Do any of these source packages build > arch > specific binaries on those architectures that no longer work, than > those > need to be removed from unstable (reportbug ftp.debian.org). > > Maybe I don't understand what you meant exactly (sorry for not having > read the full backlog). The OCaml compiler has two compilation modes: native and vm. The new version disabled the native mode on 32bits architectures. Some packages that were ok with the last version aren't anymore. Hope that makes things clearer, J.Puydt
Bug#1061476: transition: elpi
Package: release.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org Severity: normal there is a new upstream for elpi in the OCaml packages, which has an impact on a few Coq packages. I checked locally (using sbuild in a chroot) everything could move fine. Several packages need a new version and then some need just a rebuild. A ben description of the plan is in post scriptum. Waiting for your ACK to upload the new packages sources. Thanks, J.Puydt PS: dw coq-elpi 2.0.0-1 . ANY . -m 'elpi >= 1.18.1-1' dw coq-hierarchy-builder_1.7.0-1 . ANY . -m 'coq-elpi >= 2.0.0-1' dw ssreflect_2.2.0-1 . ANY . -m 'coq-hierarchy-builder >= 1.7.0-1' dw coq-relation-algebra_1.7.10-1 . ANY . -m 'ssreflect >= 2.2.0-1' dw mathcomp-finmap_2.1.0-1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coq-deriving_0.2.0-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw coq-deriving_0.2.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coq-reglang_1.2.1-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw coq-reglang_1.2.1-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coquelicot_3.4.1-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw coquelicot_3.4.1-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu mathcomp-bigenough_1.0.1-12+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw mathcomp-bigenough_1.0.1-12+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu mathcomp-zify_1.5.0+2.0+8.16-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw mathcomp-zify_1.5.0+2.0+8.16-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coq-quickchick_2.0.2-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw coq-quickchick_2.0.2-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coq-extructures_0.4.0-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1 coq-deriving=0.2.0-1+b1' dw coq-extructures_0.4.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' dw coq-extructures_0.4.0-1+b1 . ANY . -m 'coq-deriving >= 0.2.0-1+b1' nmu coq-interval_4.9.0-1+b2 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1 coquelicot=3.4.1-1+b1' dw coq-interval_4.9.0-1+b2 . ANY . -m 'ssreflect >= 2.2.0-1' dw coq-interval_4.9.0-1+b2 . ANY . -m 'coquelicot >= 3.4.1-1+b1' nmu mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1 mathcomp-zify=1.5.0+2.0+8.16-1+b1 coq- elpi=2.0.0-1' dw mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'ssreflect >= 2.2.0- 1' dw mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'mathcomp-zify >= 1.5.0+2.0+8.16-1+b1' dw mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'coq-elpi >= 2.0.0- 1' nmu mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1 mathcomp-finmap=2.1.0-1 mathcomp- bigenough=1.0.1-12+b1' dw mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' dw mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'mathcomp-finmap >= 2.1.0-1' dw mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'mathcomp-bigenough >= 1.0.1-12+b1' nmu mathcomp-real-closed_2.0.0-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1 mathcomp-bigenough=1.0.1-12+b1' dw mathcomp-real-closed_2.0.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' dw mathcomp-real-closed_2.0.0-1+b1 . ANY . -m 'mathcomp-bigenough >= 1.0.1-12+b1' nmu coqeal_2.0.1-1+b1 . ANY . -m 'Rebuild because of upload of mathcomp-real-closed=2.0.0-1+b1 ssreflect=2.2.0-1' dw coqeal_2.0.1-1+b1 . ANY . -m 'mathcomp-real-closed >= 2.0.0-1+b1' dw coqeal_2.0.1-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
Bug#1061476: Updated ben script
Hi, someone uploaded a new mathcomp-analysis not knowing about this planned transition, so it should be taken into account. Cheers, J.Puydt PS: updated ben script dw coq-elpi_2.0.0-1 . ANY . -m 'elpi >= 1.18.1-1' dw coq-hierarchy-builder_1.7.0-1 . ANY . -m 'coq-elpi >= 2.0.0-1' dw ssreflect_2.2.0-1 . ANY . -m 'coq-hierarchy-builder >= 1.7.0-1' dw coq-relation-algebra_1.7.10-1 . ANY . -m 'ssreflect >= 2.2.0-1' dw mathcomp-finmap_2.1.0-1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coq-deriving_0.2.0-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw coq-deriving_0.2.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coq-reglang_1.2.1-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw coq-reglang_1.2.1-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coquelicot_3.4.1-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw coquelicot_3.4.1-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu mathcomp-bigenough_1.0.1-12+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw mathcomp-bigenough_1.0.1-12+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu mathcomp-zify_1.5.0+2.0+8.16-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw mathcomp-zify_1.5.0+2.0+8.16-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coq-quickchick_2.0.2-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1' dw coq-quickchick_2.0.2-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coq-extructures_0.4.0-1+b1 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1 coq-deriving=0.2.0-1+b1' dw coq-extructures_0.4.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' dw coq-extructures_0.4.0-1+b1 . ANY . -m 'coq-deriving >= 0.2.0-1+b1' nmu coq-interval_4.9.0-1+b2 . ANY . -m 'Rebuild because of upload of ssreflect=2.2.0-1 coquelicot=3.4.1-1+b1' dw coq-interval_4.9.0-1+b2 . ANY . -m 'ssreflect >= 2.2.0-1' dw coq-interval_4.9.0-1+b2 . ANY . -m 'coquelicot >= 3.4.1-1+b1' nmu mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'Rebuild because of upload of mathcomp-zify=1.5.0+2.0+8.16-1+b1 ssreflect=2.2.0-1 coq- elpi=2.0.0-1' dw mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'mathcomp-zify >= 1.5.0+2.0+8.16-1+b1' dw mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'ssreflect >= 2.2.0- 1' dw mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'coq-elpi >= 2.0.0- 1' nmu mathcomp-analysis_1.0.0-1+b1 . ANY . -m 'Rebuild because of upload of coq-hierarchy-builder=1.7.0-1 coq-elpi=2.0.0-1 mathcomp- bigenough=1.0.1-12+b1 mathcomp-finmap=2.1.0-1 ssreflect=2.2.0-1' dw mathcomp-analysis_1.0.0-1+b1 . ANY . -m 'coq-hierarchy-builder >= 1.7.0-1' dw mathcomp-analysis_1.0.0-1+b1 . ANY . -m 'coq-elpi >= 2.0.0-1' dw mathcomp-analysis_1.0.0-1+b1 . ANY . -m 'mathcomp-bigenough >= 1.0.1-12+b1' dw mathcomp-analysis_1.0.0-1+b1 . ANY . -m 'mathcomp-finmap >= 2.1.0- 1' dw mathcomp-analysis_1.0.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'Rebuild because of upload of mathcomp-bigenough=1.0.1-12+b1 mathcomp-finmap=2.1.0-1 ssreflect=2.2.0-1' dw mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'mathcomp-bigenough >= 1.0.1-12+b1' dw mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'mathcomp-finmap >= 2.1.0-1' dw mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu mathcomp-real-closed_2.0.0-1+b1 . ANY . -m 'Rebuild because of upload of mathcomp-bigenough=1.0.1-12+b1 ssreflect=2.2.0-1' dw mathcomp-real-closed_2.0.0-1+b1 . ANY . -m 'mathcomp-bigenough >= 1.0.1-12+b1' dw mathcomp-real-closed_2.0.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1' nmu coqeal_2.0.1-1+b1 . ANY . -m 'Rebuild because of upload of mathcomp-real-closed=2.0.0-1+b1 ssreflect=2.2.0-1' dw coqeal_2.0.1-1+b1 . ANY . -m 'mathcomp-real-closed >= 2.0.0-1+b1' dw coqeal_2.0.1-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
Bug#1061476: Transition slot for elpi
Hi, is there a particular problem with what I'm proposing? I checked and didn't see any collision with an ocaml transition or some such. Thanks, J.Puydt
Bug#1061476: Transition slot for elpi
Hi, Le vendredi 09 février 2024 à 10:19 +0100, Sebastian Ramacher a écrit : > Hi Julien > > On 2024-02-09 10:06:28 +0100, julien.pu...@gmail.com wrote: > > Hi, > > > > is there a particular problem with what I'm proposing? I checked > > and > > didn't see any collision with an ocaml transition or some such. > > Until the time_t transition is done, we won't process other > transition. > Normal operation will continue after the time_t transition. Ah, good! Thanks! J
Please binNMU linbox against the new libntl
Hi, the version of libntl which has been recently uploaded in unstable has rdepends on three packages: eclib, flint and linbox. Both eclib & flint have either new versions or need a bugfix, and will be pushed shortly. It leaves linbox to care about : it doesn't need a bugfix and is already the latest upstream, so a binNMU against this new version of libntl is called for. nmu linbox_1.3.2-1 . ALL . -m "Rebuild against libntl 6.2.1-1" Thanks, Snark on #debian-science -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5424.9010...@laposte.net
Re: Please binNMU linbox against the new libntl
Hi, Le 25/09/2014 16:44, Adam D. Barratt a écrit : On 2014-09-25 15:09, Julien Puydt wrote: the version of libntl which has been recently uploaded in unstable has rdepends on three packages: eclib, flint and linbox. Both eclib & flint have either new versions or need a bugfix, and will be pushed shortly. This is a library transition. The most recent announcement by the release team to debian-devel-announce - https://lists.debian.org/debian-devel-announce/2014/07/msg2.html - clearly stated that the deadline for new transitions to be started for jessie was September 9th, i.e. more than two weeks ago. Regards, Adam Sigh... Let's see : - I could open an RC bug on the newer libntl so it doesn't migrate to testing ; - the new eclib & flint can probably go in unstable, but again, I would also open RC bugs on them so they don't migrate to testing (the current ones are fine with the current libntl) ; - for linbox... I don't know exactly yet. Snark on #debian-science -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542448f2.9020...@laposte.net
Bug#1087631: Transition: coq 8.20
Hi Le mer. 20 nov. 2024, 09:53, Emilio Pozuelo Monfort a écrit : > On 16/11/2024 15:43, Julien Puydt wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-CC: debian-ocaml-ma...@lists.debian.org > > > > Coq version 8.20 has been out since the beginning of september. I > > prepared a coherent set of versions for the whole Coq-in-Debian set of > > packages (45 packages). > > > > I need a transition slot before I upload anything. > > Have you done any local rebuilds to ensure that packages build fine > against the > new coq version? > Yes, that is what I meant when I wrote I prepared a coherent set ; sorry if I wasn't clear. Thanks, JP >
Bug#1087631: Transition: coq 8.20
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debian-ocaml-ma...@lists.debian.org Coq version 8.20 has been out since the beginning of september. I prepared a coherent set of versions for the whole Coq-in-Debian set of packages (45 packages). I need a transition slot before I upload anything. Cheers, J.Puydt PS: the relevant transition script is : dw aac-tactics_8.20.0-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-dpdgraph_1.0+8.20-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-elpi_2.2.3-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-elpi_2.2.3-1 . ANY . -m 'elpi >= 1.19.6-1' dw coq-ext-lib_0.12.2-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-hammer_1.3.2+8.20-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-hott_8.20-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-menhirlib_20240715+ds-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-serapi_8.20.0+0.20.0-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-stdpp_1.11.0-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-unicoq_1.6-8.19-3 . ANY . -m 'coq >= 8.20.0-1' dw coq-unimath_20240923-1 . ANY . -m 'coq >= 8.20.0-1' dw flocq_4.2.0-1 . ANY . -m 'coq >= 8.20.0-1' dw paramcoq_1.1.3+coq8.20 . ANY . -m 'coq >= 8.20.0-1' nmu coq-bignums_9.0.0+coq8.20-1+b5 . ANY . -m 'Rebuild because of upload of coq=8.20.0-1' dw coq-bignums_9.0.0+coq8.20-1+b5 . ANY . -m 'coq >= 8.20.0-1' nmu coq-libhyps_2.0.8-4+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.0-1' dw coq-libhyps_2.0.8-4+b4 . ANY . -m 'coq >= 8.20.0-1' nmu coq-record-update_0.3.4-3+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.0-1' dw coq-record-update_0.3.4-3+b4 . ANY . -m 'coq >= 8.20.0-1' nmu coq-reduction-effects_0.1.5-5+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.0-1' dw coq-reduction-effects_0.1.5-5+b4 . ANY . -m 'coq >= 8.20.0-1' nmu ott_0.33+ds-4+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.0-1' dw ott_0.33+ds-4+b4 . ANY . -m 'coq >= 8.20.0-1' dw coq-equations_1.3.1-8.20-1 . ANY . -m 'coq-hott >= 8.20-1' dw coq-equations_1.3.1-8.20-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-iris_4.3.0-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-iris_4.3.0-1 . ANY . -m 'coq-stdpp >= 1.11.0-1' dw coq-mtac2_1.40+8.19-3 . ANY . -m 'coq-unicoq >= 1.6-8.19-3' dw coq-mtac2_1.40+8.19-3 . ANY . -m 'coq >= 8.20.0-1' dw coq-simple-io_1.10.0-1 . ANY . -m 'coq-ext-lib >= 0.12.2-1' dw coq-simple-io_1.10.0-1 . ANY . -m 'coq >= 8.20.0-1' nmu coq-gappa_1.5.5-2+b4 . ANY . -m 'Rebuild because of upload of flocq=4.2.0-1 coq=8.20.0-1' dw coq-gappa_1.5.5-2+b4 . ANY . -m 'flocq >= 4.2.0-1' dw coq-gappa_1.5.5-2+b4 . ANY . -m 'coq >= 8.20.0-1' nmu coq-hierarchy-builder_1.7.0-2+b10 . ANY . -m 'Rebuild because of upload of coq=8.20.0-1 coq-elpi=2.2.3-1' dw coq-hierarchy-builder_1.7.0-2+b10 . ANY . -m 'coq >= 8.20.0-1' dw coq-hierarchy-builder_1.7.0-2+b10 . ANY . -m 'coq-elpi >= 2.2.3-1' nmu coq-math-classes_8.19.0-1+b7 . ANY . -m 'Rebuild because of upload of coq-bignums=9.0.0+coq8.20-1+b5 coq=8.20.0-1' dw coq-math-classes_8.19.0-1+b7 . ANY . -m 'coq-bignums >= 9.0.0+coq8.20-1+b5' dw coq-math-classes_8.19.0-1+b7 . ANY . -m 'coq >= 8.20.0-1' nmu coqprime_8.19-2+b4 . ANY . -m 'Rebuild because of upload of coq- bignums=9.0.0+coq8.20-1+b5 coq=8.20.0-1' dw coqprime_8.19-2+b4 . ANY . -m 'coq-bignums >= 9.0.0+coq8.20-1+b5' dw coqprime_8.19-2+b4 . ANY . -m 'coq >= 8.20.0-1' dw coq-corn_8.19.0+ds1-2 . ANY . -m 'coq-bignums >= 9.0.0+coq8.20- 1+b5' dw coq-corn_8.19.0+ds1-2 . ANY . -m 'coq >= 8.20.0-1' dw coq-corn_8.19.0+ds1-2 . ANY . -m 'coq-math-classes >= 8.19.0-1+b7' nmu ssreflect_2.2.0-2+b9 . ANY . -m 'Rebuild because of upload of coq- hierarchy-builder=1.7.0-2+b10 coq=8.20.0-1' dw ssreflect_2.2.0-2+b9 . ANY . -m 'coq-hierarchy-builder >= 1.7.0- 2+b10' dw ssreflect_2.2.0-2+b9 . ANY . -m 'coq >= 8.20.0-1' dw coq-relation-algebra_1.7.11-1 . ANY . -m 'aac-tactics >= 8.20.0-1' dw coq-relation-algebra_1.7.11-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-relation-algebra_1.7.11-1 . ANY . -m 'ssreflect >= 2.2.0-2+b9' dw coquelicot_3.4.2-1 . ANY . -m 'coq >= 8.20.0-1' dw coquelicot_3.4.2-1 . ANY . -m 'ssreflect >= 2.2.0-2+b9' dw coq-quickchick_2.0.4-1 . ANY . -m 'coq-simple-io >= 1.10.0-1' dw coq-quickchick_2.0.4-1 . ANY . -m 'coq-ext-lib >= 0.12.2-1' dw coq-quickchick_2.0.4-1 . ANY . -m 'coq >= 8.20.0-1' dw coq-quickchick_2.0.4-1 . ANY . -m 'ssreflect >= 2.2.0-2+b9' nmu coq-deriving_0.2.0-3+b7 . ANY . -m 'Rebuild because of upload of coq=8.20.0-1 ssreflect=2.2.0-2+b9' dw coq-deriving_0.2.0-3+b7 . ANY . -m 'coq >= 8.20.0-1' dw coq-deriving_0.2.0-3+b7 . ANY . -m 'ssreflect >= 2.2.0-2+b9' nmu coq-reglang_1.2.1-4+b7 . ANY . -m 'Rebuild because of upload of coq=8.20.0-1 ssreflect=2.2.0-2+b9' dw coq-reglang_1.2.1-4+b7 . ANY . -m 'coq >= 8.20.0-1' dw coq-reglang_1.2.1-4+b7 . ANY . -m 'ssreflect >= 2.2.0-2+b9' nmu mathcomp-bigenough_1.0.1-14+b7 . ANY . -m 'Rebuild because of upload of coq=8.20.0-1 ssreflect=2.2.0-2+b9' dw mathcomp-bigenough_1.0.1-14+b7 . ANY . -m 'coq >= 8.20.0-1' dw mathcomp-bigen
Bug#1091458: transition: coq-ext-lib
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debian-ocaml-ma...@lists.debian.org A new coq-ext-lib version is out and two other packages need to be recompiled. I checked them locally so I'm sure this transition will run smoothly. I'll upload the new coq-ext-lib when you'll give me the go. Cheers, J.Puydt PS: the relevant transition script is : nmu coq-simple-io_1.10.0-1+b1 . ANY . -m 'Rebuild because of upload of coq-ext-lib=0.13.0-1' dw coq-simple-io_1.10.0-1+b1 . ANY . -m 'coq-ext-lib >= 0.13.0-1' nmu coq-quickchick_2.0.5-1+b2 . ANY . -m 'Rebuild because of upload of coq-ext-lib=0.13.0-1 coq-simple-io=1.10.0-1+b1' dw coq-quickchick_2.0.5-1+b2 . ANY . -m 'coq-ext-lib >= 0.13.0-1' dw coq-quickchick_2.0.5-1+b2 . ANY . -m 'coq-simple-io >= 1.10.0-1+b1'
Bug#1090727: transition: elpi
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debian-ocaml-ma...@lists.debian.org A new elpi version is out and a few other packages need to be updated. I checked the whole set of depending packages to update or recompile so this transition to happen smoothly. I need a transition slot before I upload anything. Cheers, J.Puydt PS: the relevant transition script is : dw coq-elpi_2.3.0-1 . ANY . -m 'elpi >= 2.0.5-1' dw coq-hierarchy-builder_1.8.0-1 . ANY . -m 'coq-elpi >= 2.3.0-1' dw ssreflect_2.3.0-1 . ANY . -m 'coq-hierarchy-builder >= 1.8.0-1' dw coq-deriving_0.2.1-1 . ANY . -m 'ssreflect >= 2.3.0-1' dw coq-quickchick_2.0.5-1 . ANY . -m 'ssreflect >= 2.3.0-1' nmu coq-reglang_1.2.1-4+b9 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1' dw coq-reglang_1.2.1-4+b9 . ANY . -m 'ssreflect >= 2.3.0-1' nmu coq-relation-algebra_1.7.11-1+b2 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1' dw coq-relation-algebra_1.7.11-1+b2 . ANY . -m 'ssreflect >= 2.3.0-1' nmu coquelicot_3.4.2-1+b2 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1' dw coquelicot_3.4.2-1+b2 . ANY . -m 'ssreflect >= 2.3.0-1' nmu mathcomp-bigenough_1.0.1-14+b8 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1' dw mathcomp-bigenough_1.0.1-14+b8 . ANY . -m 'ssreflect >= 2.3.0-1' nmu mathcomp-finmap_2.1.0-3+b2 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1' dw mathcomp-finmap_2.1.0-3+b2 . ANY . -m 'ssreflect >= 2.3.0-1' nmu mathcomp-zify_1.5.0+2.0+8.16-4+b2 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1' dw mathcomp-zify_1.5.0+2.0+8.16-4+b2 . ANY . -m 'ssreflect >= 2.3.0-1' dw coq-extructures_0.5.0-1 . ANY . -m 'coq-deriving >= 0.2.1-1' dw coq-extructures_0.5.0-1 . ANY . -m 'ssreflect >= 2.3.0-1' dw mathcomp-multinomials_2.3.0-1 . ANY . -m 'ssreflect >= 2.3.0-1' dw mathcomp-multinomials_2.3.0-1 . ANY . -m 'mathcomp-finmap >= 2.1.0- 3+b2' dw mathcomp-multinomials_2.3.0-1 . ANY . -m 'mathcomp-bigenough >= 1.0.1-14+b8' dw mathcomp-real-closed_2.0.2-1 . ANY . -m 'ssreflect >= 2.3.0-1' dw mathcomp-real-closed_2.0.2-1 . ANY . -m 'mathcomp-bigenough >= 1.0.1-14+b8' nmu coq-interval_4.11.1-1+b4 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1 coquelicot=3.4.2-1+b2' dw coq-interval_4.11.1-1+b4 . ANY . -m 'ssreflect >= 2.3.0-1' dw coq-interval_4.11.1-1+b4 . ANY . -m 'coquelicot >= 3.4.2-1+b2' nmu mathcomp-algebra-tactics_1.2.3-4+b9 . ANY . -m 'Rebuild because of upload of mathcomp-zify=1.5.0+2.0+8.16-4+b2 ssreflect=2.3.0-1 coq- elpi=2.3.0-1' dw mathcomp-algebra-tactics_1.2.3-4+b9 . ANY . -m 'mathcomp-zify >= 1.5.0+2.0+8.16-4+b2' dw mathcomp-algebra-tactics_1.2.3-4+b9 . ANY . -m 'ssreflect >= 2.3.0- 1' dw mathcomp-algebra-tactics_1.2.3-4+b9 . ANY . -m 'coq-elpi >= 2.3.0- 1' nmu mathcomp-analysis_1.7.0-1+b2 . ANY . -m 'Rebuild because of upload of mathcomp-finmap=2.1.0-3+b2 coq-hierarchy-builder=1.8.0-1 ssreflect=2.3.0-1 mathcomp-bigenough=1.0.1-14+b8 coq-elpi=2.3.0-1' dw mathcomp-analysis_1.7.0-1+b2 . ANY . -m 'mathcomp-finmap >= 2.1.0- 3+b2' dw mathcomp-analysis_1.7.0-1+b2 . ANY . -m 'coq-hierarchy-builder >= 1.8.0-1' dw mathcomp-analysis_1.7.0-1+b2 . ANY . -m 'ssreflect >= 2.3.0-1' dw mathcomp-analysis_1.7.0-1+b2 . ANY . -m 'mathcomp-bigenough >= 1.0.1-14+b8' dw mathcomp-analysis_1.7.0-1+b2 . ANY . -m 'coq-elpi >= 2.3.0-1' dw coqeal_2.0.3-1 . ANY . -m 'ssreflect >= 2.3.0-1' dw coqeal_2.0.3-1 . ANY . -m 'mathcomp-real-closed >= 2.0.2-1'
Bug#1096036: transition: coq 8.20.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers A new upstream version of Coq is out ; it requires rebuilding all depending packages, and updating some of them (see below). I'm waiting for the "go!" signal to upload the new packages. Cheers, J.Puydt PS: the upgrade path: dw flocq_4.2.1-1 . ANY . -m 'coq >= 8.20.1-1' dw coq-elpi_2.4.0-1 . ANY . -m 'coq >= 8.20.1-1' dw coq-elpi_2.4.0-1 . ANY . -m 'elpi >= 2.0.7-1' dw coq-hott_9.0-1 . ANY . -m 'coq >= 8.20.1-1' nmu aac-tactics_8.20.0-1+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw aac-tactics_8.20.0-1+b4 . ANY . -m 'coq >= 8.20.1-1' nmu coq-bignums_9.0.0+coq8.20-1+b9 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-bignums_9.0.0+coq8.20-1+b9 . ANY . -m 'coq >= 8.20.1-1' nmu coq-dpdgraph_1.0+8.20-1+b3 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-dpdgraph_1.0+8.20-1+b3 . ANY . -m 'coq >= 8.20.1-1' nmu coq-ext-lib_0.13.0-1+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-ext-lib_0.13.0-1+b4 . ANY . -m 'coq >= 8.20.1-1' nmu coq-hammer_1.3.2+8.20-1+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-hammer_1.3.2+8.20-1+b4 . ANY . -m 'coq >= 8.20.1-1' nmu coq-libhyps_2.0.8-4+b8 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-libhyps_2.0.8-4+b8 . ANY . -m 'coq >= 8.20.1-1' nmu coq-menhirlib_20240715+ds-1+b6 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-menhirlib_20240715+ds-1+b6 . ANY . -m 'coq >= 8.20.1-1' nmu coq-record-update_0.3.4-4+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-record-update_0.3.4-4+b4 . ANY . -m 'coq >= 8.20.1-1' nmu coq-reduction-effects_0.1.5-5+b8 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-reduction-effects_0.1.5-5+b8 . ANY . -m 'coq >= 8.20.1-1' nmu coq-stdpp_1.11.0-1+b6 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-stdpp_1.11.0-1+b6 . ANY . -m 'coq >= 8.20.1-1' nmu coq-unicoq_1.6-8.20-1+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-unicoq_1.6-8.20-1+b4 . ANY . -m 'coq >= 8.20.1-1' nmu coq-unimath_20240923-2+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-unimath_20240923-2+b4 . ANY . -m 'coq >= 8.20.1-1' nmu ott_0.34+ds-1+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw ott_0.34+ds-1+b4 . ANY . -m 'coq >= 8.20.1-1' nmu paramcoq_1.1.3+coq8.20-1+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw paramcoq_1.1.3+coq8.20-1+b4 . ANY . -m 'coq >= 8.20.1-1' nmu coq-serapi_8.20.0+0.20.0-1+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1' dw coq-serapi_8.20.0+0.20.0-1+b4 . ANY . -m 'coq >= 8.20.1-1' dw coq-hierarchy-builder_1.8.1-1 . ANY . -m 'coq >= 8.20.1-1' dw coq-hierarchy-builder_1.8.1-1 . ANY . -m 'coq-elpi >= 2.4.0-1' nmu coq-equations_1.3.1-8.20-1+b4 . ANY . -m 'Rebuild because of upload of coq-hott=9.0-1 coq=8.20.1-1' dw coq-equations_1.3.1-8.20-1+b4 . ANY . -m 'coq-hott >= 9.0-1' dw coq-equations_1.3.1-8.20-1+b4 . ANY . -m 'coq >= 8.20.1-1' nmu coq-gappa_1.6.0-1+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1 flocq=4.2.1-1' dw coq-gappa_1.6.0-1+b4 . ANY . -m 'coq >= 8.20.1-1' dw coq-gappa_1.6.0-1+b4 . ANY . -m 'flocq >= 4.2.1-1' nmu coq-iris_4.3.0-1+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1 coq-stdpp=1.11.0-1+b6' dw coq-iris_4.3.0-1+b4 . ANY . -m 'coq >= 8.20.1-1' dw coq-iris_4.3.0-1+b4 . ANY . -m 'coq-stdpp >= 1.11.0-1+b6' nmu coq-math-classes_8.19.0-1+b11 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1 coq-bignums=9.0.0+coq8.20-1+b9' dw coq-math-classes_8.19.0-1+b11 . ANY . -m 'coq >= 8.20.1-1' dw coq-math-classes_8.19.0-1+b11 . ANY . -m 'coq-bignums >= 9.0.0+coq8.20-1+b9' nmu coq-mtac2_1.4+8.20-1+b4 . ANY . -m 'Rebuild because of upload of coq-unicoq=1.6-8.20-1+b4 coq=8.20.1-1' dw coq-mtac2_1.4+8.20-1+b4 . ANY . -m 'coq-unicoq >= 1.6-8.20-1+b4' dw coq-mtac2_1.4+8.20-1+b4 . ANY . -m 'coq >= 8.20.1-1' nmu coq-simple-io_1.10.0-1+b6 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1 coq-ext-lib=0.13.0-1+b4' dw coq-simple-io_1.10.0-1+b6 . ANY . -m 'coq >= 8.20.1-1' dw coq-simple-io_1.10.0-1+b6 . ANY . -m 'coq-ext-lib >= 0.13.0-1+b4' nmu coqprime_8.20.1-1+b4 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1 coq-bignums=9.0.0+coq8.20-1+b9' dw coqprime_8.20.1-1+b4 . ANY . -m 'coq >= 8.20.1-1' dw coqprime_8.20.1-1+b4 . ANY . -m 'coq-bignums >= 9.0.0+coq8.20-1+b9' dw coq-corn_8.20.0-1 . ANY . -m 'coq >= 8.20.1-1' dw coq-corn_8.20.0-1 . ANY . -m 'coq-bignums >= 9.0.0+coq8.20-1+b9' dw coq-corn_8.20.0-1 . ANY . -m 'coq-math-classes >= 8.19.0-1+b11' dw coq-corn_8.20.0-1 . ANY . -m 'coq-elpi >= 2.4.0-1' nmu ssreflect_2.3.0-1+b6 . ANY . -m 'Rebuild because of upload of coq=8.20.1-1 coq-hierarchy-builder=1.8.1-1' dw ssreflect_2.3.0-1+b6 . ANY . -m 'coq >= 8.20.1-1' dw ssreflect_2.3.0-1+b6 . ANY .
Bug#1100177: transition: coq-elpi 2.5.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers A new upstream version of coq-elpi is out ; it requires rebuilding all depending packages, and updating some of them (see below). I'm waiting for the "go!" signal to upload the new packages. Cheers, J.Puydt PS: here is the transition script, obtained using: coq-wanna-build coq-elpi 2.5.0-1 coq-quickchick 2.1.0-1 coqeal 2.1.0-1 nmu coq-hierarchy-builder_1.8.1-1+b2 . ANY . -m 'Rebuild because of upload of coq-elpi=2.5.0-1' dw coq-hierarchy-builder_1.8.1-1+b2 . ANY . -m 'coq-elpi >= 2.5.0-1' nmu coq-corn_8.20.0-1+b2 . ANY . -m 'Rebuild because of upload of coq- elpi=2.5.0-1' dw coq-corn_8.20.0-1+b2 . ANY . -m 'coq-elpi >= 2.5.0-1' nmu ssreflect_2.3.0-1+b7 . ANY . -m 'Rebuild because of upload of coq- hierarchy-builder=1.8.1-1+b2' dw ssreflect_2.3.0-1+b7 . ANY . -m 'coq-hierarchy-builder >= 1.8.1- 1+b2' dw coq-quickchick_2.1.0-1 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu coq-deriving_0.2.1-1+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw coq-deriving_0.2.1-1+b6 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu coq-reglang_1.2.1-4+b13 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw coq-reglang_1.2.1-4+b13 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu coq-relation-algebra_1.7.11-1+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw coq-relation-algebra_1.7.11-1+b6 . ANY . -m 'ssreflect >= 2.3.0- 1+b7' nmu coquelicot_3.4.3-1+b2 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw coquelicot_3.4.3-1+b2 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu mathcomp-bigenough_1.0.2-1+b3 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw mathcomp-bigenough_1.0.2-1+b3 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu mathcomp-finmap_2.1.0-3+b7 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw mathcomp-finmap_2.1.0-3+b7 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu mathcomp-zify_1.5.0+2.0+8.16-4+b7 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw mathcomp-zify_1.5.0+2.0+8.16-4+b7 . ANY . -m 'ssreflect >= 2.3.0- 1+b7' nmu mathcomp-algebra-tactics_1.2.4-1+b4 . ANY . -m 'Rebuild because of upload of coq-elpi=2.5.0-1 mathcomp-zify=1.5.0+2.0+8.16-4+b7 ssreflect=2.3.0-1+b7' dw mathcomp-algebra-tactics_1.2.4-1+b4 . ANY . -m 'coq-elpi >= 2.5.0- 1' dw mathcomp-algebra-tactics_1.2.4-1+b4 . ANY . -m 'mathcomp-zify >= 1.5.0+2.0+8.16-4+b7' dw mathcomp-algebra-tactics_1.2.4-1+b4 . ANY . -m 'ssreflect >= 2.3.0- 1+b7' nmu mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'Rebuild because of upload of mathcomp-finmap=2.1.0-3+b7 mathcomp-bigenough=1.0.2-1+b3 coq- elpi=2.5.0-1 coq-hierarchy-builder=1.8.1-1+b2 ssreflect=2.3.0-1+b7' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'mathcomp-finmap >= 2.1.0- 3+b7' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'mathcomp-bigenough >= 1.0.2-1+b3' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'coq-elpi >= 2.5.0-1' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'coq-hierarchy-builder >= 1.8.1-1+b2' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu coq-extructures_0.5.0-1+b6 . ANY . -m 'Rebuild because of upload of coq-deriving=0.2.1-1+b6 ssreflect=2.3.0-1+b7' dw coq-extructures_0.5.0-1+b6 . ANY . -m 'coq-deriving >= 0.2.1-1+b6' dw coq-extructures_0.5.0-1+b6 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu coq-interval_4.11.1-1+b8 . ANY . -m 'Rebuild because of upload of coquelicot=3.4.3-1+b2 ssreflect=2.3.0-1+b7' dw coq-interval_4.11.1-1+b8 . ANY . -m 'coquelicot >= 3.4.3-1+b2' dw coq-interval_4.11.1-1+b8 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu mathcomp-multinomials_2.3.0-1+b7 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7 mathcomp-finmap=2.1.0-3+b7 mathcomp- bigenough=1.0.2-1+b3' dw mathcomp-multinomials_2.3.0-1+b7 . ANY . -m 'ssreflect >= 2.3.0- 1+b7' dw mathcomp-multinomials_2.3.0-1+b7 . ANY . -m 'mathcomp-finmap >= 2.1.0-3+b7' dw mathcomp-multinomials_2.3.0-1+b7 . ANY . -m 'mathcomp-bigenough >= 1.0.2-1+b3' nmu mathcomp-real-closed_2.0.2-1+b7 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7 mathcomp-bigenough=1.0.2-1+b3' dw mathcomp-real-closed_2.0.2-1+b7 . ANY . -m 'ssreflect >= 2.3.0- 1+b7' dw mathcomp-real-closed_2.0.2-1+b7 . ANY . -m 'mathcomp-bigenough >= 1.0.2-1+b3' dw coqeal_2.1.0-1 . ANY . -m 'ssreflect >= 2.3.0-1+b7' dw coqeal_2.1.0-1 . ANY . -m 'mathcomp-real-closed >= 2.0.2-1+b7'
Bug#1100416: transition: coq-elpi, coq-quickchick, coq-simple-io and coqeal
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers A new upstream version of coq-elpi, coq-quickchick, coq-simple-io and coqeal are out ; they require rebuilding all depending packages (see below). I'm waiting for the "go!" signal to upload the new packages. Cheers, J.Puydt PS: running "coq-wanna-build coq-elpi 2.5.0-1 coq-quickchick 2.1.0-1 coqeal 2.1.0-1 coq-simple-io 1.11.0-1" gives the following transition script: nmu coq-hierarchy-builder_1.8.1-1+b1 . ANY . -m 'Rebuild because of upload of coq-elpi=2.5.0-1' dw coq-hierarchy-builder_1.8.1-1+b1 . ANY . -m 'coq-elpi >= 2.5.0-1' nmu coq-corn_8.20.0-1+b2 . ANY . -m 'Rebuild because of upload of coq- elpi=2.5.0-1' dw coq-corn_8.20.0-1+b2 . ANY . -m 'coq-elpi >= 2.5.0-1' nmu ssreflect_2.3.0-1+b6 . ANY . -m 'Rebuild because of upload of coq- hierarchy-builder=1.8.1-1+b1' dw ssreflect_2.3.0-1+b6 . ANY . -m 'coq-hierarchy-builder >= 1.8.1- 1+b1' dw coq-quickchick_2.1.0-1 . ANY . -m 'ssreflect >= 2.3.0-1+b6' dw coq-quickchick_2.1.0-1 . ANY . -m 'coq-simple-io >= 1.11.0-1' nmu coq-deriving_0.2.1-1+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6' dw coq-deriving_0.2.1-1+b6 . ANY . -m 'ssreflect >= 2.3.0-1+b6' nmu coq-reglang_1.2.1-4+b13 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6' dw coq-reglang_1.2.1-4+b13 . ANY . -m 'ssreflect >= 2.3.0-1+b6' nmu coq-relation-algebra_1.7.11-1+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6' dw coq-relation-algebra_1.7.11-1+b6 . ANY . -m 'ssreflect >= 2.3.0- 1+b6' nmu coquelicot_3.4.3-1+b2 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6' dw coquelicot_3.4.3-1+b2 . ANY . -m 'ssreflect >= 2.3.0-1+b6' nmu mathcomp-bigenough_1.0.2-1+b2 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6' dw mathcomp-bigenough_1.0.2-1+b2 . ANY . -m 'ssreflect >= 2.3.0-1+b6' nmu mathcomp-finmap_2.1.0-3+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6' dw mathcomp-finmap_2.1.0-3+b6 . ANY . -m 'ssreflect >= 2.3.0-1+b6' nmu mathcomp-zify_1.5.0+2.0+8.16-4+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6' dw mathcomp-zify_1.5.0+2.0+8.16-4+b6 . ANY . -m 'ssreflect >= 2.3.0- 1+b6' nmu mathcomp-algebra-tactics_1.2.4-1+b3 . ANY . -m 'Rebuild because of upload of mathcomp-zify=1.5.0+2.0+8.16-4+b6 ssreflect=2.3.0-1+b6 coq- elpi=2.5.0-1' dw mathcomp-algebra-tactics_1.2.4-1+b3 . ANY . -m 'mathcomp-zify >= 1.5.0+2.0+8.16-4+b6' dw mathcomp-algebra-tactics_1.2.4-1+b3 . ANY . -m 'ssreflect >= 2.3.0- 1+b6' dw mathcomp-algebra-tactics_1.2.4-1+b3 . ANY . -m 'coq-elpi >= 2.5.0- 1' nmu mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'Rebuild because of upload of coq-elpi=2.5.0-1 coq-hierarchy-builder=1.8.1-1+b1 ssreflect=2.3.0- 1+b6 mathcomp-finmap=2.1.0-3+b6 mathcomp-bigenough=1.0.2-1+b2' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'coq-elpi >= 2.5.0-1' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'coq-hierarchy-builder >= 1.8.1-1+b1' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'ssreflect >= 2.3.0-1+b6' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'mathcomp-finmap >= 2.1.0- 3+b6' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'mathcomp-bigenough >= 1.0.2-1+b2' nmu coq-extructures_0.5.0-1+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6 coq-deriving=0.2.1-1+b6' dw coq-extructures_0.5.0-1+b6 . ANY . -m 'ssreflect >= 2.3.0-1+b6' dw coq-extructures_0.5.0-1+b6 . ANY . -m 'coq-deriving >= 0.2.1-1+b6' nmu coq-interval_4.11.1-1+b8 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6 coquelicot=3.4.3-1+b2' dw coq-interval_4.11.1-1+b8 . ANY . -m 'ssreflect >= 2.3.0-1+b6' dw coq-interval_4.11.1-1+b8 . ANY . -m 'coquelicot >= 3.4.3-1+b2' nmu mathcomp-multinomials_2.3.0-1+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6 mathcomp-finmap=2.1.0-3+b6 mathcomp- bigenough=1.0.2-1+b2' dw mathcomp-multinomials_2.3.0-1+b6 . ANY . -m 'ssreflect >= 2.3.0- 1+b6' dw mathcomp-multinomials_2.3.0-1+b6 . ANY . -m 'mathcomp-finmap >= 2.1.0-3+b6' dw mathcomp-multinomials_2.3.0-1+b6 . ANY . -m 'mathcomp-bigenough >= 1.0.2-1+b2' nmu mathcomp-real-closed_2.0.2-1+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b6 mathcomp-bigenough=1.0.2-1+b2' dw mathcomp-real-closed_2.0.2-1+b6 . ANY . -m 'ssreflect >= 2.3.0- 1+b6' dw mathcomp-real-closed_2.0.2-1+b6 . ANY . -m 'mathcomp-bigenough >= 1.0.2-1+b2' dw coqeal_2.1.0-1 . ANY . -m 'ssreflect >= 2.3.0-1+b6' dw coqeal_2.1.0-1 . ANY . -m 'mathcomp-real-closed >= 2.0.2-1+b6'
Bug#1100416: transition: coq-elpi, coq-quickchick, coq-simple-io and coqeal
Hi, Le jeu. 13 mars 2025, 17:29, Emilio Pozuelo Monfort a écrit : > On 13/03/2025 17:21, Julien Puydt wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: jpu...@debian.org > > X-Debbugs-Cc: Debian OCaml Maintainers > > > > > > A new upstream version of coq-elpi, coq-quickchick, coq-simple-io and > > coqeal are out ; they require rebuilding all depending packages (see > > below). > > > > I'm waiting for the "go!" signal to upload the new packages. > > Do the rdeps build against the new versions? > Yes, they do. J.Puydt >
