Bug#1050027: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#1050027: fixed in mathcomp-analysis 0.6.4-2)
Le 19/08/2023 à 21:25, julien.pu...@gmail.com a écrit : I'm sorry. Adding Breaks is necessary but insufficient. You also need Replaces. What is in libcoq-mathcomp-analysis << 0.6.4 is now in two packages: - libcoq-mathcomp-classical (a small part) ; - libcoq-mathcomp-analysis (the most part -- and that binary package depends on libcoq-mathcomp-classical with a strong version constraint). This situation is explicitly covered in Policy 7.3 and 7.6.1. The problem you pointed was that a user with an old libcoq-mathcomp- analysis asking to install libcoq-mathcomp-classical would lead dpkg to a conflict of files. The breaks I added prevents that, and in fact a user with an old licoq-mathcomp-analysis should have no issue in those situations: (1) try to install a newer libcoq-mathcomp-classical -- with my Breaks dpkg will refuse because of the conflict which is a sane answer : system not broken, features not broken ; (2) try to upgrade - dpkg will see the new libcoq-mathcomp-analysis needs libcoq-mathcomp-classical and that it breaks the outgoing libcoq- mathcomp-analysis, but it's able to handle the situation ; If I declare libcoq-mathcomp-classical Replaces libcoq-mathcomp- analysis << 0.6.4, then in situation (1), dpkg will install libcoq- mathcomp-classical and drop that old libcoq-mathcomp-analysis. The system is not broken, but the user just lost most of the functionality, and that is bad. So I think the change I made is sound. Although it might be sound, my understanding is that it make upgrades unnecessarily difficult: without the Replaces, one has to completely deconfigure the old libcoq-mathcomp-analysis (and its reverse-dependencies) before installing the new one. Do you have another problem in mind? Or a better fix? The better fix is to add Breaks *and* Replaces, as instructed by Helmut and Policy. Cheers, -- Stéphane
ocaml-mad 0.5.2-3 MIGRATED to testing
FYI: The status of the ocaml-mad source package in Debian's testing distribution has changed. Previous version: 0.5.2-2 Current version: 0.5.2-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information.
Processed: unblock
Processing commands for cont...@bugs.debian.org: > unblock 967501 by 967559 Bug #967501 [src:gtkspell] gtkspell: depends on deprecated GTK 2 967501 was blocked by: 967694 967559 967713 967764 967501 was blocking: 947713 Removed blocking bug(s) of 967501: 967559 > unblock 967849 by 967559 Bug #967849 [src:gtkspell] gtkspell: deprecated in favour of gtkspell3 967849 was blocked by: 967528 967819 967894 967559 967764 967893 967713 967694 967445 967849 was not blocking any bugs. Removed blocking bug(s) of 967849: 967559 > End of message, stopping processing here. Please contact me if you need assistance. -- 967501: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967501 967849: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967849 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: block 1040757 with 1041164
Processing commands for cont...@bugs.debian.org: > block 1040757 with 1041164 Bug #1040757 [qa.debian.org] dose: (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe 1040757 was not blocked by any bugs. 1040757 was not blocking any bugs. Added blocking bug(s) of 1040757: 1041164 > thanks Stopping processing here. Please contact me if you need assistance. -- 1040757: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040757 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1041164: dose-distcheck: fails with (W)Dose_common: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe"
For the record : this seems to be related to the option "--latest 1" discarding Essential packages. Here is a minimal Packages file for reproducing the bug: Package: aa Source: aa Version: 1 Essential: yes Architecture: all Package: aa Source: aa Version: 2 Architecture: all -Ralf.
Bug#1050178: ocaml-extunix FTBFS on hppa
Package: ocaml-extunix Tags: ftbfs, hppa Version: 0.4.1-3 This package fails like this: Failure: tests:7:resource:0:setrlimit:1:RLIMIT_STACK soft limit expected: infinity but got: 8388608 see: https://buildd.debian.org/status/fetch.php?pkg=ocaml-extunix&arch=hppa&ver=0.4.1-3&stamp=1692284259&raw=0 The problem is, that on hppa a "unlimited stack" means "80MB" stack by default. Reason is, that on hppa the stack grows upwards, so on hppa there always needs to be a configurable stack (up to a limit). Can you please apply that patch (at least for hppa) so that the build succeeds? Thanks, Helge diff -up ./test/test.ml.org ./test/test.ml --- ./test/test.ml.org 2023-08-21 13:42:33.779667564 + +++ ./test/test.ml 2023-08-21 14:00:18.226077993 + @@ -132,7 +132,7 @@ let test_resource = RLIMIT_DATA; RLIMIT_FSIZE; (* RLIMIT_NOFILE; *) (* too fragile to test on CI *) -RLIMIT_STACK; +(* RLIMIT_STACK; *) (* at least on hppa stack unlimited means 80MB *) RLIMIT_AS; ] in