Bug#1050027: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#1050027: fixed in mathcomp-analysis 0.6.4-2)

2023-08-21 Thread Stéphane Glondu

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

2023-08-21 Thread Debian testing watch
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

2023-08-21 Thread Debian Bug Tracking System
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

2023-08-21 Thread Debian Bug Tracking System
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"

2023-08-21 Thread Ralf Treinen
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

2023-08-21 Thread Helge Deller
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