Bug#1065751: Confirmed
Hi, I can just confirm that whatever was done breaks usage of gbp import- orig --uscan. Cheers, J.Puydt
Bug#1064854: Breaks tex-common's configuration
Package: context Version: 2023.05.05.20230730+dfsg-2 Severity: critical since a few days, I saw a configuration issue with the tex-common package. (What I don't get is why it actually needs configuration since I don't see uploads since months.) I finally found the time to investigate and report. The error message is: Setting up tex-common (6.18) ... Running mktexlsr. This may take some time... done. Running mtxrun --generate. This may take some time... mtxrun --generate failed. Output has been stored in /tmp/mtxrun.F4nq0y9x Please include this file if you report a bug. where /tmp/mtxrun.* contains a single line: lua error : startup file: /usr/bin/mtxrun.lua:2438: attempt to assign to const variable 'i' The executable /usr/bin/mtxrun.lua is provided by the context package (which also wasn't updated also since months...) In /usr/bin/mtxrun.lua, around line 2438 looks like: for i,v in next,t do if type(i)=="table" then if tables[i] then i=tables[i] <- 2438 is that one else i=copy(i,tables) end end my guess is the correct value should be put in another variable than the for-loop index, but I'm pretty clueless about lua, and it did work at some point... perhaps a new lua version is pickier? Anyway I'm filing the bug report against context, since uninstalling it unbreaks things, and setting the gravity level to critical since it breaks other packages. Cheers, J.Puydt
Bug#1063596: flint: FTBFS on amd64: test segfault
Hi, I just compiled the package without any issue. A case of eigenbug where you compile three times and it only fails one? Cheers, 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
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: 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#1060988: marked as done (mathcomp-analysis: FTBFS: make[3]: *** [Makefile.coq:838: classical/mathcomp_extra.vo] Error 1)
Hi, Le lundi 29 janvier 2024 à 09:39 +, Debian Bug Tracking System a écrit : > Your message dated Mon, 29 Jan 2024 09:35:04 + > with message-id > and subject line Bug#1060988: fixed in mathcomp-analysis 1.0.0-1 > has caused the Debian Bug report #1060988, > regarding mathcomp-analysis: FTBFS: make[3]: *** [Makefile.coq:838: > classical/mathcomp_extra.vo] Error 1 > to be marked as done. > > This means that you claim that the problem has been dealt with. > If this is not the case it is now your responsibility to reopen the > Bug report if necessary, and/or fix the problem forthwith. > > (NB: If you are a system administrator and have no idea what this > message is talking about, this may indicate a serious mail system > misconfiguration somewhere. Please contact ow...@bugs.debian.org > immediately.) I had a transition planned, and as the new mathcomp-analysis wasn't out yet when I requested it, it wasn't part of its ben script... I'll upload manually a -2 when time will come. Cheers, J.Puydt
Bug#1052826: Broken entrypoints package: actually a pybuild issue?
Hi, Le dimanche 28 janvier 2024 à 08:17 +0100, Andreas Tille a écrit : > Hi Jullien, > > upstream page[1] says: > > This package is in maintenance-only mode. New code should use the > importlib.metadata module in the Python standard library to find > and load entry points. > > So it seems we do not need adapt you patch very frequently since > no changes will be to be expected (but the dependencies of entrypoint > should be adapted. Doesn't that mean that we should strive to RM entrypoints? Cheers, J.Puydt PS: I really mean "strive to" and not "do it": $ ssh mirror.ftp-master.debian.org "dak rm -Rn entrypoints" Will remove the following packages from unstable: entrypoints | 0.4-2 | source python3-entrypoints | 0.4-2 | all Maintainer: Debian Python Team --- Reason --- -- Checking reverse dependencies... # Broken Depends: intake: python3-intake ipyparallel: python3-ipyparallel jupyter-client: python3-jupyter-client nbconvert: python3-nbconvert python-altair: python3-altair # Broken Build-Depends: intake: python3-entrypoints jupyter-client: python3-entrypoints jupyter-notebook: python3-entrypoints jupyterhub: python3-entrypoints nbconvert: python3-entrypoints nbsphinx: python3-entrypoints oscrypto: python3-entrypoints python-altair: python3-entrypoints python-flake8: python3-entrypoints Dependency problem found.
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#1052826: Broken entrypoints package: actually a pybuild issue?
Hi,
I found the source of the breakage for the entrypoints package: its
tests/samples/ directory contains a few files describing mock Python
packages, and the tests consist in running functions on those and check
the answers match what is expected.
Alas, something (and I suspect pybuild) removes the *.egg-info
directories there, so of course results don't match.
I see two ways out:
(1) configure something so tests/samples/ doesn't get touched ;
(2) patch the tests to adapt them to the modified directories.
Solution (2) is pretty fast, pretty easy and extremely dirty: it will
need an update for each upstream change and that basically means the
tests don't actually test anything.
Solution (1) is much more reliable, but I neither know if it's possible
nor how - can someone lend a hand?
Thanks!
J.Puydt
PS: the patch would be that ugly:
Description: fix bug #1052826 (broken tests)
Author: Julien Puydt
Forwarded: not needed
--- entrypoints.orig/tests/test_entrypoints.py
+++ entrypoints/tests/test_entrypoints.py
@@ -19,31 +19,31 @@
def test_iter_files_distros():
result = entrypoints.iter_files_distros(path=sample_path)
-# the sample_path has 4 unique items so iter_files_distros returns
4 tuples
-assert len(list(result)) == 4
+# the sample_path has 3 unique items so iter_files_distros returns
3 tuples
+assert len(list(result)) == 3
# testing a development, egg aka installed with pip install -e .
# these don't have version info in the .egg-info directory name
# (eg dev-0.0.1.egg-info)
path_with_dev = [osp.join(samples_dir, 'packages4')]
result = entrypoints.iter_files_distros(path=path_with_dev)
-assert len(list(result)) == 1
+assert len(list(result)) == 0
# duplicate dev versions should still return one result
path_with_dev_duplicates = path_with_dev * 2
result =
entrypoints.iter_files_distros(path=path_with_dev_duplicates)
-assert len(list(result)) == 1
+assert len(list(result)) == 0
def test_get_group_all():
group = entrypoints.get_group_all('entrypoints.test1',
sample_path)
print(group)
-assert len(group) == 5
-assert {ep.name for ep in group} == {'abc', 'rew', 'opo', 'njn'}
+assert len(group) == 3
+assert {ep.name for ep in group} == {'abc', 'rew', 'njn'}
def test_get_group_named():
group = entrypoints.get_group_named('entrypoints.test1',
sample_path)
print(group)
-assert len(group) == 4
+assert len(group) == 3
assert group['abc'].module_name == 'foo'
assert group['abc'].object_name == 'abc'
Bug#1061232: src:coq: fails to migrate to testing for too long: triggers autopkgtest issues
Hi, Le dimanche 21 janvier 2024 à 21:38 +0100, Paul Gevers a écrit : > Hi, > > On 21-01-2024 21:06, julien.pu...@gmail.com wrote: > > Would kicking the mathcomp-analysis package out of testing allow > > the > > migration of the rest of the Coq-related packages and at least give > > a > > coherent set there? > > It seems src:mathcomp-analysis is a leaf package that can easily be > removed indeed. > It is. > > That would still leave mathcomp-analysis broken in > > unstable, of course, but that's a lesser evil. > > Indeed. . > > If the issue isn't cleared for testing by february first, I'll just > > ask for a full RM of mathcomp-analysis : a brutal fix, but an > > efficient one. > > Well, I think that if the package (once fixed) is still useful to > have in Debian, temporary removal from testing is a reasonable trick > to solve situations like this, no need for a full RM. Once fixed it > can migrate again. Obviously if you think the situation for this > package in Debian is bad, than full RM makes sense of course. Well, I have some code depending on it as a user... broken since that long, so yes it would be useful. But if upstream doesn't follow the ecosystem timely, I might have to port my code around it to stay current. As a DD... I'm quite annoyed to see the upstream side of the ecosystem move and the Debian side get frozen for a single package. > I have added a removal hint (for removal from testing). Thanks, that will be a relief to at least save testing from this mess. Thanks again, J.Puydt
Bug#1061232: src:coq: fails to migrate to testing for too long: triggers autopkgtest issues
Hi, Le dimanche 21 janvier 2024 à 08:42 +0100, Paul Gevers a écrit : > Source: coq > Version: 8.17.0+dfsg-1 > Severity: serious > Control: close -1 8.18.0+dfsg-1 > Tags: sid trixie > User: release.debian@packages.debian.org > Usertags: out-of-sync > > Dear maintainer(s), > > The Release Team considers packages that are out-of-sync between > testing and unstable for more than 30 days as having a Release > Critical bug in testing [1]. Your package src:coq has been trying to > migrate for 31 days > [2]. Hence, I am filing this bug. The version in unstable causes > autopkgtest failures in multiple reverse (test) dependencies: > mathcomp-analysis (affected by FTBFS bug 1060988) and mathcomp-finmap > (which has a newer version in unstable with issues). > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot > be fixed via unstable. Additionally, blocked packages can have impact > on other packages, which makes preparing for the release more > difficult. > Finally, it often exposes issues with the package and/or > its (reverse-)dependencies. We expect maintainers to fix issues that > hamper the migration of their package in a timely manner. > > This bug will trigger auto-removal when appropriate. As with all new > bugs, there will be at least 30 days before the package is auto- > removed. > > I have immediately closed this bug with the version in unstable, so > if > that version or a later version migrates, this bug will no longer > affect > testing. I have also tagged this bug to only affect sid and trixie, > so > it doesn't affect (old-)stable. > > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release > Team. I fixed the mathcomp-finmap issue in unstable, so in two days (too young excuse) that will leave only mathcomp-analysis blocking Coq- related packages from migrating as far as I can tell. The problem with mathcomp-analysis is that: - I had understood upstream would release a version compatible with "MC 2" (ssreflect package in Debian) by the end of december, so I started uploading the whole set (about fifty packages) even though I didn't have that good version yet, pretty confident the breakage would be transitory, perhaps even invisible since it's a leaf package ; - but then the new compatible release would come in january ; - and now january is coming to an end without it ; - in fact there was a new release three days ago to add compatibility with the yet-unreleased next Coq... but still "MC 1"! The conclusion is: I shouldn't have jumped the gun. Would kicking the mathcomp-analysis package out of testing allow the migration of the rest of the Coq-related packages and at least give a coherent set there? That would still leave mathcomp-analysis broken in unstable, of course, but that's a lesser evil. If the issue isn't cleared for testing by february first, I'll just ask for a full RM of mathcomp-analysis : a brutal fix, but an efficient one. Thanks, J.Puydt
Bug#1056062: About Debian bug #1056062 (coq package)
Hi, can you tell me why you declared coq package's version 8.18.0+dfsg-1 is still affected by the issue? Your message was less than informative! Cheers, J.Puydt
Bug#1060027: RM: setuptools-scm-git-archive -- ROM; obsoleted by setuptools-scm 7
Hi, Le jeudi 04 janvier 2024 à 21:03 -0400, Stefano Rivera a écrit : > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: remove > X-Debbugs-Cc: setuptools-scm-git-arch...@packages.debian.org, > jpu...@debian.org > Control: affects -1 + src:setuptools-scm-git-archive > > setuptools-scm-git-archive is broken by setuptools-scm 8. > > It was obsoleted by setuptools-scm 7, so there is no reason to keep > it in the archive. I've been following the situation since quite long, but it's not ready to go yet as far as my notes say: - for cheroot, we need to wait for the next upstream version: https://github.com/cherrypy/cheroot/issues/515 - for matplotlib, the next Debian upload will drop it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050105 - for python-jira, the next Debian upload will drop it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050102 - for satpy, we need to wait for the next upstream version: https://github.com/pytroll/satpy/issues/2549 - for xsar, upstream still depends on it: https://github.com/umr-lops/xsar/issues/191 I hope this helps, J.Puydt
Bug#1059271: RM: antic -- ROM; subsumed
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: an...@packages.debian.org, Debian Math Team , jpu...@debian.org Control: affects -1 + src:antic Upstream merged src:antic into src:flint, and we already have src:flint, so we don't need src:antic anymore. dak confirms all packages migrated to the new scheme, so it's ready to go. Cheers, J.Puydt
Bug#1059229: RM: mathcomp-abel -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: mathcomp-a...@packages.debian.org, Debian OCaml Maintainers , jpu...@debian.org Control: affects -1 + src:mathcomp-abel Hi, tagging it as abandoned is a bit excessive -- it's just that upstream doesn't keep the software updated with the rest of the Coq ecosystem on a regular basis, so making sure it works with the rest of the Coq-related packages in Debian is going to be extremely painful. It's a leaf package, and not a very useful one at that, so we can drop it. Cheers, J.Puydt
Bug#1059090: elpi: add build support for loongarch64
Hi, Le mer. 20 déc. 2023, 07:27, zhangdandan a écrit : > Source: elpi > Version: 8.5.4-1 > Severity: wishlist > Tags: patch > User: debian-loonga...@lists.debian.org > Usertags: loong64 > > Dear maintainers, > > The elpi source package lacks LoongArch architecture support. > We need to add build support for loongarch64 in d/control, for examples, > ``` > Package: libelpi-ocaml > -Architecture: amd64 arm64 i386 ppc64el ppc64 riscv64 sh4 > +Architecture: amd64 arm64 i386 loong64 ppc64el ppc64 riscv64 sh4 > > Package: libelpi-ocaml-dev > -Architecture: amd64 arm64 i386 ppc64el ppc64 riscv64 sh4 > +Architecture: amd64 arm64 i386 loong64 ppc64el ppc64 riscv64 sh4 > > Package: elpi > -Architecture: amd64 arm64 i386 ppc64el ppc64 riscv64 sh4 > +Architecture: amd64 arm64 i386 loong64 ppc64el ppc64 riscv64 sh4 > ``` > I'm ok with adding support for the architecture. I would like to remind you that the compilation dependencies of loong64 > elpi are not yet satisfied. > If you have any questions, you can contact me at any time. > I guess you're working your way up and you want to remove future easy hurdles already. I'll get this out of your way, but notice all Coq packages are mostly blocked since weeks - I'll push the change for elpi on salsa but won't upload before I can get everything in shape, probably not before january. Cheers, J.Puydt >
Bug#1058916: RM: calcium -- RoM; obsolete
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: calc...@packages.debian.org, Debian Math Team , jpu...@debian.org Control: affects -1 + src:calcium Calcium is now included in the newer versions of the flint package, so we don't need a separate package anymore for the next Debian. Cheers, J.Puydt
Bug#1056062: coq: FTBFS in sid (dune update?)
Hi, Le mercredi 22 novembre 2023 à 18:48 +0100, Gianfranco Costamagna a écrit : > control: tags -1 patch > > Hello, not sure why and how, but this upstream commit > fbe9e28b667e795a5ceb41bd7784bd2ea7ab10bf > > https://launchpadlibrarian.net/699029680/coq_8.17.0+dfsg-1build4_8.17.0+dfsg-1ubuntu1.diff.gz > > Subject: [PATCH] make-library-index: use mktemp, general cleanup > > This fixes the "sed: can't read tmp" error on my machine, not that I > understand why it happened. > > Looks fixing the issue > Good: that means the problem will be fixed when I'll be able to upload 8.18.0+dfsg-1 to unstable. control: fixed -1 8.18.0+dfsg-1 Thanks! J.Puydt
Bug#1056062: coq: FTBFS in sid (dune update?)
Hi, Le jeudi 16 novembre 2023 à 16:45 +0100, Gianfranco Costamagna a écrit : > Source: coq > Version: 8.17.0+dfsg-1 > Severity: serious > > Hello, > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/coq.html > > As said here, there is a build failure due to probably new dune or > something similar. > > > I can reproduce locally, but not always, looks some concurrency issue > but also running dune with -j1 doesn't fix the issue. I couldn't reproduce your failure even after several compilation tries, neither with the current 8.17.0+dfsg-1 nor with the next 8.18.0+dfsg-1. > $ (cd _build/default && /usr/bin/bash -e -u -o pipefail -c > 'doc/stdlib/make-library-index doc/stdlib/index-list.html > doc/stdlib/hidden-files') > Building file index-list.prehtml... Error: none of doc/stdlib/index- > list.html and doc/stdlib/hidden-files mention > theories/Arith/Between.v > grep: tmp: No such file or directory > grep: tmp: No such file or directory > > This is probably the culprit of the issue, but I don't really > understand why this is not found > I checked doc/stdlib/index-list.html.template in both 8.17.0+dfsg-1 and 8.18.0+dfsg-1, and they *do* mention theories/Arith/Between.v... how could that line disappear? Is it always theories/Arith/Between.v or sometimes another file? The compilation of the .html.template to .html might fail silently for you and then you see a later breakage? > and also why running it manually works > bash -e -u -o pipefail -c 'doc/stdlib/make-library-index > doc/stdlib/index-list.html doc/stdlib/hidden-files' > Building file index-list.prehtml... > Done > > Sorry for not providing a patch, but I really don't have much > knowledge about this build system, and despite my efforts I'm still > failing The fact that the only error message doesn't make sense and the problem isn't guaranteed to happen is puzzling. I'm using sbuild to compile my sources, with an unstable schroot I keep up to date, and it now uses ocaml-dune 3.11.1-1 to compile, just like in your failure log :-/ Thanks, JP
Bug#1053319: Retained file handles after a tab was closed
Package: firefox-esr Version: 115.3.0esr-1 I only report it now because I noticed this recently, but I don't think I had the issue in last may. On one of the sites I have to use professionally, after a file was uploaded and I disconnect from the site and close the tab, lsof shows the file handle is still used by firefox ; and if the file is on an usb key, I have to force the ejection as it means it's seen as busy (which is how I detected the issue). Cheers, J.Puydt
Bug#1043252: Next OCaml transition: 4.14.x
Hi Le lun. 18 sept. 2023, 09:37, Stéphane Glondu a écrit : > > OCaml 5.1.0 has just been released, and a version 4.14.2 will soon be > released. Current version in unstable is 4.13.1. > > I played a bit with opam-debian-switch, and it turns out that (at least) > 35 packages are broken (at the moment) with OCaml 5.1.0 whereas only 1 > seems broken with 4.14.1. > > Therefore, I am planning to migrate to 4.14.x first. > I agree with that plan ; can you list which packages get broken in each case? Notice that as far as I know Coq isn't broken by the new OCaml but has performance issues with it - the Coq and OCaml upstreams are trying to fix this, so I expect new versions of both will get out when that will be fixed. Cheers, J.Puydt >
Bug#1050322: Partial versus complete replacement of a package by another
Hi, Le mercredi 23 août 2023 à 08:45 +0100, Simon McVittie a écrit : > No, the central misunderstanding here is that you think Replaces will > have the effect of instructing dpkg to remove the replaced package > completely, which is not the case. Oh. I think I had two problems: (1) thinking "Replaces" meant "replaces" ; (2) thinking d/control controlled packages. Let me try to see if I'm getting at something: (*) Replaces doesn't really mean "can be used in place of" -- that would be expressed with Breaks+Provides. (*) Replaces shouldn't come without Breaks, but doesn't imply it so we have to put in both (why?). (*) Breaks+Replaces is partial replacement. (*) A complete replacement can be achieved with: (+) just the same package name (the most usual situation, explicit in d/control) (+) Breaks+Replaces and all files of the other package are overriden (triggers removal of the other, *not* seen in d/control!); (+) Conflicts+Replaces (forcing removal of the other, explicit in d/control). (*) In 7.6.1's example, what happens if the system has foo 1.2-2 and the user tries to install foo-data 1.2-3? Do we end up with foo 1.2-2 and foo-data 1.2-3 unpacked and apt/dpkg complaining it can't configure them or does it refuse with a clear error message? Thanks, J.Puydt
Bug#1050027: libcoq-mathcomp-classical: undeclared file conflict with libcoq-mathcomp-analysis/bookworm+trixie
Le mercredi 23 août 2023 à 09:07 +0100, Simon McVittie a écrit : > On Wed, 23 Aug 2023 at 08:41:44 +0200, julien.pu...@gmail.com wrote: > > let's lower the severity to avoid blocking migration during the > > discussion -- after all the Breaks already avoids the file conflict > > issue. > > Sorry, no, it does not. What Helmut said looks correct. > > The Breaks prevents apt from installing the new libcoq-mathcomp- > classical > without also upgrading or deconfiguring libcoq-mathcomp-analysis, but > does not constrain the order in which apt/dpkg will carry out the > upgrade. > > If they happen to have chosen this order of operations, which is what > happened when I tried an upgrade from bookworm to sid, and presumably > also what you saw in your own testing: > > 1. unpack the new libcoq-mathcomp-analysis > (leaving its dependency on libcoq-mathcomp-classical temporarily > unsatisfied - the overall state of the system is "partially > broken") > 2. unpack the new libcoq-mathcomp-classical > 3. configure libcoq-mathcomp-classical > 4. configure libcoq-mathcomp-analysis > (the system is back to a consistent state) > > then the file-overwrite will be avoided. But if it chooses this order > of operations: > > 1. temporarily mark the old libcoq-mathcomp-analysis as deconfigured > (again, the overall state of the system is "partially broken") > 2. unpack the new libcoq-mathcomp-classical > 3. unpack the new libcoq-mathcomp-analysis > 4. configure libcoq-mathcomp-classical > 5. configure libcoq-mathcomp-analysis > (the system is back to a consistent state) > > then step 2 is going to fail, because the old libcoq-mathcomp- > analysis > contained files also present in the new libcoq-mathcomp-classical. > (Symptom: "trying to overwrite x, which is also in package y") > > With the current metadata, there is no guarantee which of those > two upgrade sequences apt will choose. It is common for bugs of this > category to not happen during the maintainer's testing, but then be > easily > reproducible by other users who have more/different packages > installed, > which makes apt choose a slightly different upgrade path. I'll just fix the bug like you want to avoid blocking other packages, but I really do not understand, so I'll continue asking on the debian- policy bug to get things clarified. Cheers, J.Puydt
Bug#1050322: Partial versus complete replacement of a package by another
Package: debian-policy
Version: 4.6.2.0
Severity: normal
Hi,
over at bug #1050027 there is a discussion of applicable policy when
splitting a package. I'll first explain what the bug is about and then
why that's a problem with the Policy.
The src:mathcomp-analysis package provided a single binary package
libcoq-mathcomp-analysis until 0.6.3-2 ; with 0.6.4-1, it's now
providing two binary packages libcoq-mathcomp-analysis and libcoq-
mathcomp-classical. The binary package libcoq-mathcomp-analysis Depends
on libcoq-mathcomp-classical (= ${binary:Version}). And with 0.6.4-1,
that Depends was the only information, so of course file conflicts
weren't handled correctly, and that is what #1050027 is about.
In src:mathcomp-analysis 0.6.4-2, I declared that libcoq-mathcomp-
classical Breaks libcoq-mathcomp-analysis (<< 0.6.4) and closed the
bug. It was swiftly re-opened because I hadn't used Breaks+Replaces
according to Policy 7.6.1. But I don't want to use Replaces as libcoq-
mathcomp-classical isn't a *complete* replacement for libcoq-mathcomp-
analysis (<< 0.6.4) -- it only provides a small part of it!
So what does the Policy actually say?
In section 7.3 it discusses the use of Breaks to avoid file conflicts -
- and on that point it's pretty clear.
The problem is with section 7.6 on how to use Replaces: indeed, the
very first paragraph of 7.6 mentions "two distinct purposes", partial
and complete replacement... but the rest of the section is all about
complete replacement -- and it's using Breaks+Replaces for that. What
relationship fields combination corresponds to *partial* replacement?
As far as I can tell it doesn't say!
Subsection 7.6.1 explains that Replaces without Breaks shouldn't happen
(not clearly enough: #1050221).
In fact subsection 7.6.1 has an example which looks exactly like
#1050027, but it looks wrong: if foo 1.2-2 is installed on a system and
foo-data 1.2-3's installation is requested, then because of Breaks dpkg
will know about the file conflicts and beware, but because of Replaces,
it will think it's a complete replacement -- foo will disappear if I
understand well. The system will stay coherent but the user will have
lost features...
My understanding of relationship fields mechanics is:
| | Breaks | no Breaks |
|-+--+|
| Replaces| complete replacement | 7.6.1: no! |
| no Replaces | partial replacement | very usual |
But that indeed isn't in the Policy per se, so I'm asking for
clarification.
Cheers,
J.Puydt
Bug#1050027: Stop blocking other packages migration
Control: severity -1 normal Hi, let's lower the severity to avoid blocking migration during the discussion -- after all the Breaks already avoids the file conflict issue. Cheers, J.Puydt
Bug#1050027: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#1050027: fixed in mathcomp-analysis 0.6.4-2)
Le mardi 22 août 2023 à 08:34 +0200, Stéphane Glondu a écrit :
>
> This situation is explicitly covered in Policy 7.3 and 7.6.1.
Section 7.3 explains why the Breaks is needed when there are file
conflicts ; we agree on that point and hence 0.6.4-2 got it.
Section 7.6 is about partial and complete replacement according to its
very first paragraph ("two distinct purposes"), but doesn't make the
difference afterwards and I think that's the source of our
disagreement. The whole section 7.6 is in fact only about
Breaks+Replaces -- but that makes only one use, and clearly the
"complete replacement" one where's the "partial replacement" use?
Section 7.6.1 does explain why a Replaces calls for a Breaks (a single
sentence and a footnote -- I just filed bug #1050221 to make those a
paragraph since it seems pretty important), so this should clearly not
happen.
As I interpret Breaks+Replaces as meaning complete replacement, and
since libcoq-mathcomp-classical isn't a complete replacement, I am
reluctant to add Replaces - that's why 0.6.4-2 doesn't have it.
But indeed subsection 7.6.1's example looks exactly like what we want
and says Breaks+Replace... but where is it made clear it's only a
*partial* replacement? If we have a system with foo 1.2-2 installed and
we ask for foo-data's 1.2-3's installation, what happens?
As I understand it, the Breaks means dpkg will know about the file
conflicts so foo-data 1.2-3 and foo 1.2-2 won't both end up on the
system. But the Replaces tells it that foo-data 1.2-3 can overtake foo
1.2-2. So it should remove foo 1.2-2 and install foo-data 1.2-3 as
requested. No more foo on the system! And that's wrong...
Here is a table summarizing what I understood of the use of Breaks and
Replaces :
| Breaks | no Breaks |
|-+--+|
| Replaces| complete replacement | 7.6.1: no! |
| no Replaces | partial replacement | very usual |
Whatever this discussion gives, I think debian-policy will need a
clarification...
Cheers,
J.Puydt
Bug#1050221: Upgrade a foot note to a paragraph
Package: debian-policy Version: 4.6.2.0 Severity: minor In the first paragraph of section 7.6.1 "Overwriting files in other packages" the reason why Breaks should be used when Replaces does is mentioned in a sentence and explained in a footnote. I suggest to take that sentence "Normally, Breaks should be used in conjunction with Replaces. [4]" and turn it and the content of footnote 4 into a whole second paragraph of the section since it makes things more readable. Cheers, J.Puydt
Bug#1050105: Please drop python-setuptools-scm-git-archive from b-deps
Package: matplotlib Version: 3.6.3-1 Severity: minor Upstream setuptools-scm-git-archive is obsolete -- setuptools-scm >= 7 has everything, so I would like to get it out of Debian. The upstream matplotlib 3.6.3 doesn't depend on setuptools-scm-git- archive, but the Debian package still b-deps on it -- and it's wrong: please drop that line. Thanks, J.Puydt
Bug#1050104: Please drop b-dep on python3-setuptools-scm-git-archive
Package: statsmodels Version: 0.14.0+dfsg-3 Severity: minor Hi, upstream setuptools-scm-git-archive is obsolete -- setuptools-scm >= 7 contains everything needed ; so I would like to drop the package from Debian. Unfortunately, statsmodels' d/control still mentions it as a b-dep. But that is incorrect, so it can be dropped. Thanks, J.Puydt
Bug#1050102: Drop b-dep on python-setuptools-scm-archive
Package: python-jira Version: 3.5.2-1 Severity: minor setuptools-scm-archive is obsolete, so I would like to drop its package from Debian. Unfortunately, python-jira still b-deps on it. But that can be dropped from d/control, as the build and upstream don't depend on it anyway! Cheers, J.Puydt
Bug#1050101: Drop b-dep on python3-setuptools-scm-git-archive
Package: ocrmypdf Version: 14.0.1+dfsg1 Severity: minor Upstream setuptools-scm-git-archive is obsolete, so depending packages should stop using it. And in fact, ocrmypdf (contrary to what docs/maintainers.rst says) doesn't use it anymore, at it depends on setuptools-scm >= 7 ; so I propose to get rid of the b-dep so we can kick an obsolete package out of Debian. Cheers, J.Puydt
Bug#1050027: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#1050027: fixed in mathcomp-analysis 0.6.4-2)
Le samedi 19 août 2023 à 20:58 +0200, Helmut Grohne a écrit : > Control: reopen -1 > Control: found -1 mathcomp-analysis/0.6.4-2 > > On Sat, Aug 19, 2023 at 05:33:11PM +, Debian Bug Tracking System > wrote: > > It has been closed by Debian FTP Masters > > (reply to Julien Puydt > > ). > > 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). 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. Do you have another problem in mind? Or a better fix? Cheers, J.Puydt
Bug#1050099: Drop b-dep on setuptools-scm-git-archive
Package: pyocd Version: 0.13.1+dfsg-3 Severity: minor In d/control, the b-dep on python3-setuptools-scm-git-archive can be dropped: 1. it isn't used anyway (patched out by debian/patches/0001-Update- setup.py-to-work-with-Python3.patch) ; 2. setuptools-scm-git-archive upstream is obsolete ; 3. pyocd is one of the packages holding its package in Debian. Cheers, J.Puydt
Bug#1042751: Missing deps when using "dune utop"
Package: utop Version: 2.13.1 Severity: serious After I made utop run by itself (report #1042749), I tried to run it through "dune utop" and found liblambda-term-ocaml-dev is needed for this to work. Cheers, J
Bug#1042749: Dependency issues make the package non-working after installation
Package: utop
Version: 2.13.1-1
Severity: grave
Installing the utop package leads to a non-working utop executable,
because it needs xdg. The libdune-ocaml-dev package provides xdg.
Installing the libdune-ocaml-dev package makes utop fail with:
Fatal error: exception Fl_package_base.No_such_package("uucp",
"required by `lambda-term'")
Installing libuucp-ocaml-dev makes utop run.
Perhaps dh_ocaml doesn't detect those runtime deps?
Cheers,
J
Bug#1040214: RM: alt-ergo -- RoM, obsolete, non-free
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org alt-ergo used to be free-as-in-Debian, and was packaged as such. Since then it became non-free and the latest free version is obsolete. I propose to remove the package from Debian ; according to dak there is no problem doing so: $ ssh mirror.ftp-master.debian.org "dak rm -Rn alt-ergo" Will remove the following packages from unstable: alt-ergo |2.4.2-2 | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x Maintainer: Debian OCaml Maintainers --- Reason --- -- Checking reverse dependencies... No dependency problem found. Thanks, J.Puydt
Bug#1036496: For a GUI application?
Hi, I do understand the technical request, but I don't think I can do that: mnemosyne is a graphical application and uses matplotlib to create graphs of user performance statistics... so I don't really see how to get what you ask. If you don't have a suggestion, I'll probably close that report in a while as won't-fix. Sorry, J.Puydt
Bug#1038450: patch probably available
Le mercredi 21 juin 2023 à 22:56 +0200, Adrien Nader a écrit : > On Wed, Jun 21, 2023, julien.pu...@gmail.com wrote: > > Le mardi 20 juin 2023 à 22:38 +0200, Adrien Nader a écrit : > > > > > > > > > The patch seems to fix the issue. I say "seem" because the build > > > compiled the file that was failing to build but the build is not > > > done > > > yet: emulated armhf isn't fast. :) > > > > > > But since I reprocued the build failure before, I am fairly > > > confident > > > this build will succeed. > > > > I took the commit and added it to the Debian packaging ; I now have > > a > > 20230420-4 almost ready for upload. > > > > I'm waiting for two feedbacks before I do so : > > > > 1. yours so I trust it fixes the 32-bit issue ; > > > > 2. the sbuild I started on my box to check the patch on more usual > > architectures. > > > > Thanks for your help! > > My build just finished. It only took 27 hours. It failed at the > lintian step but that was due to network issues. Uploaded, thanks again! J
Bug#1038796: ITP: ocaml-pp -- pretty printing for OCaml applications
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers * Package name: ocaml-pp Version : 1.1.2 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/ocaml-dune/pp * License : expat Programming Lang: OCaml Description : pretty printing for OCaml applications This package provides a lean alternative to the standard library's Format module. It is a depend of a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1038795: ITP: ppx-expect -- testing framework for OCaml
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers * Package name: ppx-expect Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/ppx_expect * License : expat Programming Lang: OCaml Description : testing framework for OCaml This package provides a testing framework similar to Python's cram framework for OCaml programming. It is a depend of a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1038785: ITP: ppx-inline-test -- syntax extension for in-line tests in OCaml
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers * Package name: ppx-inline-test Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/ppx_inline_test * License : expat Programming Lang: OCaml Description : syntax extension for in-line tests in OCaml This package provides a syntax extension to write in-line tests in OCaml code. It is a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1038782: ITP: ocaml-time-now -- current time for OCaml
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers * Package name: ocaml-time-now Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/time_now * License : expat Programming Lang: OCaml Description : current time for OCaml This package provides a single function to report the current time in nanoseconds since the start of the Unix epoch. It is a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1038778: ITP: ppx-base -- base set of ppx rewriters
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers * Package name: ppx-base Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/ppx_base * License : expat Programming Lang: OCaml Description : base set of ppx rewriters This package provides the base set of ppx rewriters, used to build various other Jane Street packages. It is a depend of a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1038775: ITP: ppx-globalize -- copy local values to the global heap
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers * Package name: ppx-globalize Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/ppx_globalize * License : expat Programming Lang: OCaml Description : copy local values to the global heap This package provides a ppx rewriter to copy local values to the global heap. It is a depend of a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1038772: ITP: ppx-enumerate -- list all values of a finite type
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers * Package name: ppx-enumerate Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/ppx_enumerate * License : expat Programming Lang: OCaml Description : list all values of a finite type This package generates a list with all possible values of a finite type. It is a depend of a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1038770: ITP: jst-config -- compile-time configuration for Jane Street packages
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers * Package name: jst-config Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/jst-config * License : expat Programming Lang: OCaml Description : compile-time configuration for Jane Street packages This package provides compile-time configuration for a number of Jane Street packages, and should probably only be used by them. It is a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1038450: patch probably available
Le mardi 20 juin 2023 à 22:38 +0200, Adrien Nader a écrit : > > > The patch seems to fix the issue. I say "seem" because the build > compiled the file that was failing to build but the build is not done > yet: emulated armhf isn't fast. :) > > But since I reprocued the build failure before, I am fairly confident > this build will succeed. I took the commit and added it to the Debian packaging ; I now have a 20230420-4 almost ready for upload. I'm waiting for two feedbacks before I do so : 1. yours so I trust it fixes the 32-bit issue ; 2. the sbuild I started on my box to check the patch on more usual architectures. Thanks for your help! J
Bug#1038450: patch probably available
Hi, Le mardi 20 juin 2023 à 15:35 +0200, Adrien Nader a écrit : > I was looking at the migration for coq on Ubuntu and a build failure > on armhf is preventing it. > > I expect that this issue is fixed by the following commit: > > https://github.com/UniMath/UniMath/commit/1716c078b00c18dcabf63f671e414d7ba33cb23c > > Split the proof of associators_equiv to make sure it fits inside 32 > b… > > …its (#1687) > > This is necessary to create a jscoq addon for UniMath > (https://github.com/UniMath/UniMath-jsCoq). > > I haven't tried the patch yet and wanted to ask first if you're > interested in restoring support for 32-bit arches. I honestly don't > know > if there's a lot of users on these (except maybe for JS). If you can confirm that commit solves the issue, I'll add it as a patch to the Debian packaging and drop my latest change. I'm interested in having different platforms to detect subtle breakages. Notice that I also reported to Coq upstream: https://github.com/coq/coq/issues/17749 Thanks! J
Bug#1038698: ITP: jane-street-headers -- common header files for Jane Street projects
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers * Package name: jane-street-headers Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/jane-street-headers * License : expat Programming Lang: OCaml Description : common header files for Jane Street projects This package provides C header files common to many of Jane Street software packages. It is a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1038694: ITP: ppx-assert -- provide assertions in OCaml
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers * Package name: ppx-assert Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/ppx_assert * License : expat Programming Lang: OCaml Description : provide assertions in OCaml This package provides extension nodes to compare values and raise useful errors if they differ. It is a depend of a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1038692: ITP: ppx-cold -- Provide the @cold annotation for OCaml
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-de...@lists.debian.org, Debian OCaml Maintainers , jpu...@debian.org * Package name: ppx-cold Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/ppx_cold * License : expat Programming Lang: OCaml Description : Provide the @cold annotation for OCaml This package provides the @cold annotation to program in OCaml to disable a closure optimisation. It is a depend of a depend of a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1029547: RM: libcoq-ocaml-dev -- NBS; cruft
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: c...@packages.debian.org, debian-ocaml-ma...@lists.debian.org Control: affects -1 + src:coq Dear FTP Team, Please remove all libcoq-ocaml-dev (binary) packages from unstable. They correspond to an old coq source package, but coq has stopped building them for months. 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#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#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#1025129: elpi: Please add support for "riscv64" arch
Hi, Le mercredi 30 novembre 2022 à 00:30 +0100, Manuel A. Fernandez Montecelo a écrit : > Source: elpi > Version: 1.16.7-2 > Severity: wishlist > Tags: ftbfs patch > User: debian-ri...@lists.debian.org > Usertags: riscv64 > X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org > > Hi, > > Please enable this architecture, with the patch attached or an > equivalent. > > I built it locally on hardware, it built fine just by enabling the > architecture > in debian/control, and increasing the timeout. > > I only tried with doubling the current timeot, maybe it can do with > significantly less time, but 600 from longer_timeout.patch is already > much > higher than the original 90. But if you want I can try and try to > get a more > accurate limit. > > > Thanks and cheers. I'm going to apply your changes (I already checked them on a porterbox and committed to salsa) ; but since there's an ongoing big transition, I'll wait until that has passed. There's also a new elpi upstream version I'll want to package, so I expect in a week or so I'll be able to ask for a transition to the release team and your change will go in. Thanks for your help, 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-
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#1024003: src:elpi: fails to migrate to testing for too long: make reverse (test) dependencies uninstallable
Le dimanche 13 novembre 2022 à 19:08 +0100, Paul Gevers a écrit : > Source: elpi > Version: 1.16.5-1 > Severity: serious > Control: close -1 1.16.7-2 > Tags: sid bookworm > User: release.debian@packages.debian.org > Usertags: out-of-sync > > Dear maintainer(s), > > The Release Team considers packages that are out-of-sync between > testing and unstable for more than 60 days as having a Release > Critical bug in testing [1]. Your package src:elpi has been trying to > migrate for 62 days [2]. Hence, I am filing this bug. I think > something went wrong with the rebuilds (or the order of them or > something), because elpi can't migrate because it would make libcoq- > elpi on armhf not installable and libcoq-elpi in unstable can't > migrate because two reverse test dependencies fail to install during > autopkgtesting on armhf. I have filed bugs to get those armhf binary packages removed last tuesday ; I expect they'll go away soon enough. I waited too long for elpi's upstream to fix the arch-issues before disabling them... sorry. Hopefully things will go smooth afterwards. Thanks, J.Puydt
Bug#1023940: Doesn't work: blank editor and shell panes
Package: pyzo Version: 4.11.2-1 Severity: grave Launching pyzo displays the normal window, but the shell never comes up and the editor pane never gets a prompt ; starting from a terminal makes the following messages fly by continuously: QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it? Uncaught Python exception: arguments did not match any overloaded call: QRect(): too many arguments QRect(int, int, int, int): argument 1 has unexpected type 'float' QRect(QPoint, QPoint): argument 1 has unexpected type 'float' QRect(QPoint, QSize): argument 1 has unexpected type 'float' QRect(QRect): argument 1 has unexpected type 'float' File "/usr/share/pyzo/pyzo/codeeditor/extensions/appearance.py", line 485, in paintEvent QtCore.QRect(margin, top, self.viewport().width() - 2 * margin, height), QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it? QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it? QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it? QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it? QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it? Uncaught Python exception: arguments did not match any overloaded call: QRect(): too many arguments QRect(int, int, int, int): argument 1 has unexpected type 'float' QRect(QPoint, QPoint): argument 1 has unexpected type 'float' QRect(QPoint, QSize): argument 1 has unexpected type 'float' QRect(QRect): argument 1 has unexpected type 'float' File "/usr/share/pyzo/pyzo/codeeditor/extensions/appearance.py", line 485, in paintEvent QtCore.QRect(margin, top, self.viewport().width() - 2 * margin, height), QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it? QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it? Uncaught Python exception: arguments did not match any overloaded call: QRect(): too many arguments QRect(int, int, int, int): argument 1 has unexpected type 'float' QRect(QPoint, QPoint): argument 1 has unexpected type 'float' QRect(QPoint, QSize): argument 1 has unexpected type 'float' QRect(QRect): argument 1 has unexpected type 'float' File "/usr/share/pyzo/pyzo/codeeditor/extensions/appearance.py", line 485, in paintEvent QtCore.QRect(margin, top, self.viewport().width() - 2 * margin, height), QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it? Cheers, J.Puydt
Bug#1023639: RM: elpi rdeps on armhf -- RoM
Package: ftp.debian.org X-Debbugs-CC: Debian OCaml Maintainers Please remove all binary packages depending on the already-removed src:elpi package on the armhf architecture: libcoq-elpi libcoq-hierarchy-builder coq-hierarchy-builder libcoq-mathcomp-algebra-tactics libcoq-mathcomp-analysis Sorry for not getting things right directly, J.Puydt
Bug#1023320: Not completely fixed yet
Hi, it looks like some binary packages for elpi still get in the way of many migrations to testing: - among the official ports, armhf has a 1.16.5-4 ; - I see most other unofficial ports still have 1.16.5-1 -- except m68k has a 1.16.5-2... all of those will probably be handled by the right team, but should go away too. Thanks, J.Puydt
Bug#1023320: RM: elpi 1.16.5-1 -- RoM
Package: ftp.debian.org X-Debbugs-CC: Debian OCaml Maintainers Please remove the binaries corresponding to src:elpi 1.16.5-1 (those are elpi, libelpi-ocaml and libelpi-ocaml-dev). The rationale is: upstream's 1.16.5 broke many architectures, and 1.16.5-1 showed the issue. But since upstream doesn't want to fix it -- or at least not timely, I uploaded 1.16.5-2 disabling many architectures. The remaining 1.16.5-1 binaries prevent many packages from migrating to testing, so should get out of the way. Thanks, J.Puydt
Bug#1023182: RM: minetest-mod-intllib -- RoM; obsolete
Package: ftp.debian.org X-Debbugs-CC: pkg-games-de...@lists.alioth.debian.org I packaged this years ago ; since then minetest got an internal api for i18n that makes it useless. Dak confirms it's not used in Debian: $ ssh mirror.ftp-master.debian.org "dak rm -Rn minetest-mod-intllib" Will remove the following packages from unstable: minetest-mod-intllib | 20180811-1.1 | source, all Maintainer: Debian Games Team --- Reason --- -- Checking reverse dependencies... No dependency problem found. Cheers, J.Puydt
Bug#1022549: RFP: python-hatch-nodejs-version -- Hatch plugin for versioning from a package.json file
Package: wnpp Severity: wishlist X-Debbugs-Cc: jpu...@debian.org, debian-pyt...@lists.debian.org * Package name: python-hatch-nodejs-version Version : 0.3.0 Upstream Author : Angus Hollands * URL : https://github.com/agoose77/hatch-nodejs-version * License : Expat Programming Lang: Python Description : Hatch plugin for versioning from a package.json file This package provides two Hatch plugins: - version source plugin that reads/writes the package version from the version field of the Node.js package.json file. - metadata hook plugin that reads PEP 621 metadata from the Node.js package.json file. It's a new dependency of nbformat, and I lack the time to package it myself before some time... I'll turn it into an ITP if nobody shoots first. Cheers, J.Puydt
Bug#1015179: Please update ppxlib to latest upstream
Hi, Le mardi 11 octobre 2022 à 11:26 +0200, Stéphane Glondu a écrit : > > Le 11/10/2022 à 08:26, julien.pu...@gmail.com a écrit : > > > > Could you package the latest upstream? > > > > I did as much as I could and I think I nailed it: > > Thank you for taking care of this. > > > ** packaging: ocaml-sexplib0 (protected on salsa) > > [...] > > ** packaging: janest-base (protected on salsa) > > [...] > > new version 0.15.0 (protected on salsa) > > I've set you as Maintainer in the ocaml-team group on salsa. It > should allow you to push to all packages. > Thanks, I'll try. > > Now how does one manage transition within the OCaml team? > > It depends on the transition... > > For "small" transitions (i.e. not involving OCaml itself), I just > upload the new base package and wait for the reverse-dependencies to > be broken in: > > https://release.debian.org/transitions/html/ocaml.html > > Then, I upload or binNMU the broken packages, level by level. > I think I'll do that for this one. > Sometimes, when I suspect big breakage, I prepare the transition by > recompiling on my own machine reverse-dependencies, as you seem to > have done. And I did it by hand and by trial-and-error... that was awful :-/ > For OCaml itself, I've documented how I prepare transitions: > > https://salsa.debian.org/debian/ben/-/tree/master/examples/ocaml-transition-scripts > That looks like a useful script ; the fact that it only works for full transitions can be annoying. In https://salsa.debian.org/ocaml-team/dh-coq/-/tree/master/tools , you'll see I: - prepare transitions with coq-planif-transition, which doesn't do much work for me, except it tells me which packages will be of concern and in which order I should build things -- by hand! That would need improvements... - actually manage transitions with coq-wanna-build, so that I only have to file a transition bug to the release team with what this script gave me and wait for the upload ack ; here is a recent example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019536 As I mentioned above, I think I'll work things by hand for this specific ppxlib transition, but in the future, perhaps it's possible to adapt my Coq scripts to the OCaml ecosystem? Cheers, J.Puydt
Bug#1015179: Please update ppxlib to latest upstream
Hi, Le jeudi 22 septembre 2022 à 14:44 +0200, Stéphane Glondu a écrit : > > Le 17/07/2022 à 10:17, julien.pu...@gmail.com a écrit : > > Could you package the latest upstream? I did as much as I could and I think I nailed it: ** packaging: ocaml-sexplib0 (protected on salsa) new version 0.15.1 ** packaging: ppxlib new version 0.27.0 ** packaging: janest-base (protected on salsa) new version 0.15.1 ** compilation: ocaml-sedlex new version 3.0 ** packaging: ocaml-stdio new version 0.15.0 (protected on salsa) ** packaging: ppx-sexp-conv new version 0.15.1 ** recompilation: fieldslib lwt ocaml-bitstring ocaml-parsexp ocaml-sedlex ocaml-stdio ppx-compare ppx-deriving ppx-here variantslib ** packaging: ppx-import new version 1.10.0 ** packaging: sexplib310 new version 0.15.1 ** recompilation: elpi ocaml-uri ocaml-visitors ppx-custom-printf ppx-fields-conv ppx- optcomp ppx-variants-conv lwt-log lwt-ssl mlpost ocurl ** packaging: obus new version 1.2.4 ** recompilation: bin-prot js-of-ocaml ocaml-cstruct ** recompilation: ocaml-ipaddr ppx-bin-prot ocaml-asn1-combinators ocaml-eqaf ocaml- hex ocaml-logs ** recompilation: ocaml-mirage-crypto pgocaml ** recompilation: ocaml-pbkdf ** recompilation: ocaml-x509 ** recompilation: ocaml-ca-certs ** recompilation: ocaml-conduit NOT new version 5.1.1 (breaks current ocaml-cohttp) ** packaging: ocaml-cohttp NOT new version 5.0.0 (breaks current ocsigenserver) [needs crowbar (EXP), uucp (EXP), uunf (EXP), uucd (NEW), afl- persistent (NEW)] ** recompilation: ocsigenserver ** recompilation ocsipersist ** recompilation eliom Now how does one manage transition within the OCaml team? Cheers, J.Puydt
Bug#1021334: Provide the database as XML
Package: unicode-data Severity: wishlist I would like to package a software (ocaml-uunf) whose compilation looks like: (1) download Unicode character database (big XML file) ; (2) convert it to some format ; (3) compile. and I would like to use unicode-data to drop the problematic step (1). Can you provide the data also in XML format? Thanks, J.Puydt
Bug#1021300: ITP: ocaml-uucp -- access properties of Unicode characters
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-de...@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-uucp Version : 15.0.0 Upstream Author : Daniel Bünzli * URL : https://erratique.ch/software/uucp * License : ISC Programming Lang: OCaml Description : access properties of Unicode characters This low-deps library gives access to properties of Unicode characters of the Unicode character database. It is a dep of a new dep for ocaml-cohttp. I plan to maintain it within the Debian OCaml Maintainers team. Cheers, J.Puydt
Bug#1021294: ITP: ocaml-uunf -- Unicode text normalization form library
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-de...@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-uunf Version : 15.0.0 Upstream Author : Daniel Bünzli * URL : https://erratique.ch/software/uunf/ * License : ISC Programming Lang: OCaml Description : Unicode text normalization form library Library to normalize Unicode text, supporting all forms. It is independent of IO mechanism or Unicode text data structure, and can process text without a complete in-memory representation. It is a dep of a new dep for ocaml-cohttp. I plan to maintain it within the Debian OCaml Maintainers team. Cheers, J.Puydt
Bug#1021293: ITP: ocaml-uucd -- decode data on Unicode characters off XML
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-de...@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-uucd Version : 15.0.0 Upstream Author : Daniel Bünzli * URL : https://erratique.ch/software/uucd * License : ISC Programming Lang: OCaml Description : decode data on Unicode characters off XML This OCaml module decodes data from the Unicode character database from their XML representation, to provide high-level access so that efficient representations can be extracted. It's a dep for a new dep for ocaml-cohttp ; I plan to maintain it within the Debian OCaml Maintainers team. Cheers, J.Puydt
Bug#1021269: ITP: ocaml-afl-persistent -- use afl-fuzz in persistent mode
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-de...@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-afl-persistent Version : 1.3 Upstream Author : Stephen Dolan * URL : https://github.com/stedolan/ocaml-afl-persistent * License : MIT Programming Lang: OCaml Description : use afl-fuzz in persistent mode Makes it possible to run the afl-fuzz provided by the OCaml compiler in persistent mode. I plan to maintain it within the Debian OCaml Maintainers team ; it's a dep for a new dep of ocaml-cohttp. Cheers, J.Puydt
Bug#1021246: ITP: crowbar -- library to fuzz-test code
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-de...@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: crowbar Version : 0.2.1 Upstream Author : Stephen Dolan * URL : https://github.com/stedolan/crowbar * License : Expat Programming Lang: OCaml Description : library to fuzz-test code It combines the QuickCheck-style property-based testing and the bug-finding efficiency of afl-fuzz. It's a new depend for ocaml-cohttp, and will probably comes with its own deps itself. I plan to maintain it within the Debian OCaml Maintainers team. Cheers, J.Puydt
Bug#1015179: Please update ppxlib to latest upstream
Hi, Le mardi 04 octobre 2022 à 09:51 +0200, julien.pu...@gmail.com a écrit : > > Le lundi 03 octobre 2022 à 22:04 +0200, julien.pu...@gmail.com a > écrit : > > > > Is there something like this for OCaml packages? > > > > It looks like ocaml-sexplib0's salsa repository is also protected, so > I can only do local experiments. > > > Here is where I stand at the moment: > ** packaging: ocaml-sexplib0 (protected on salsa) new version 0.15.1 ** packaging: ppxlib new version 0.27.0 ** packaging: janest-base (protected on salsa) new version 0.15.1 ** compilation: ocaml-sedlex new version 3.0 ** packaging: ocaml-stdio new version 0.15.0 (protected on salsa) ** packaging: ppx-sexp-conv new version 0.15.1 ** recompilation: fieldslib lwt ocaml-bitstring ocaml-parsexp ocaml-sedlex ocaml-stdio ppx-compare ppx-deriving ppx-here variantslib ** packaging: ppx-import new version 1.10.0 ** packaging: sexplib310 new version 0.15.1 ** recompilation: elpi ocaml-uri ocaml-visitors ppx-custom-printf ppx-fields-conv ppx- optcomp ppx-variants-conv lwt-log lwt-ssl mlpost ocurl ** packaging: obus new version 1.2.4 ** recompilation: bin-prot js-of-ocaml ocaml-cstruct ** recompilation: ocaml-ipaddr ppx-bin-prot ocaml-asn1-combinators ocaml-eqaf ocaml- hex ocaml-logs ** recompilation: ocaml-mirage-crypto pgocaml ** recompilation: ocaml-pbkdf ** recompilation: ocaml-x509 ** recompilation: ocaml-ca-certs ** packaging: ocaml-conduit new version 5.1.1 ** packaging: ocaml-cohttp new version 5.0.0 -- needs crowbar, which needs something else... I'm working on packaging the new deps Cheers, J.Puydt
Bug#1015179: Please update ppxlib to latest upstream
Hi, Le lundi 03 octobre 2022 à 22:04 +0200, julien.pu...@gmail.com a écrit : > > Is there something like this for OCaml packages? > It looks like ocaml-sexplib0's salsa repository is also protected, so I can only do local experiments. > PS: I should really clean my Coq script and put them somewhere to > limit the bus factor... I uploaded dh-coq 0.4 to NEW this morning with a new binary package providing those scripts. Cheers, J.Puydt
Bug#1015179: Please update ppxlib to latest upstream
Hi, Le jeudi 22 septembre 2022 à 14:46 +0200, julien.pu...@gmail.com a écrit : > > I'll try to work on checking again what is needed to push to unstable > when I find the time. > I found some time this evening ; but the problem I have is I don't know how to handle deps correctly for OCaml packages! For Coq packages, I have a script and I can run: $ ./planif_transition coq-foo which tells me which packages are to be handled -- and in which order. For example: $ ./planif_transition.py ssreflect 'ssreflect' 'coq-deriving', 'coq-reglang', 'coq-relation-algebra', 'coquelicot', 'mathcomp-bigenough', 'mathcomp-finmap', 'mathcomp-zify' 'coq-extructures', 'coq-interval', 'coq-quickchick', 'mathcomp-algebra- tactics', 'mathcomp-analysis', 'mathcomp-multinomials', 'mathcomp-real- closed' 'coqeal', 'mathcomp-abel' where on each line the packages can be parallel-built. Is there something like this for OCaml packages? J.Puydt PS: I should really clean my Coq script and put them somewhere to limit the bus factor...
Bug#1021177: RM: python-scandir -- RoM; obsolete; Python2-removal
Package: ftp.debian.org X-Debbugs-CC: debian-pyt...@lists.debian.org I packaged this years ago when nice features of Python 3 needed a backport to Python 2 ; those days are gone and we're moving away from Python 2 with the next release of Debian, so this package should be removed. I checked with dak and it's ok to remove it: $ ssh mirror.ftp-master.debian.org "dak rm -Rn python-scandir" Will remove the following packages from unstable: pypy-scandir | 1.10.0-4 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x python-scandir | 1.10.0-4 | source Maintainer: Debian Python Team --- Reason --- -- Checking reverse dependencies... No dependency problem found. Cheers, 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#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#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#1015179: Please update ppxlib to latest upstream
Hi, Le jeudi 22 septembre 2022 à 14:44 +0200, Stéphane Glondu a écrit : > > I've changed the settings in salsa. Can you push, now? > Yes ; I pushed the package I pushed to experimental in salsa. I'll try to work on checking again what is needed to push to unstable when I find the time. Cheers, J.Puydt
Bug#1019879: ITP: ppx-hash -- ppx writer generating hash functions
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Julien Puydt X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org Severity: wishlist * Package name: ppx-hash Version : 0.15.0 Upstream Author : Jane Street Group, LLC * URL : https://github.com/janestreet/ppx_hash * License : Expat Programming Lang: OCaml Description : ppx writer generating hash functions This package provides a ppx writer generating hash functions from type expressions and definitions I plan to support it within the Debian Ocaml Maintainers team ; it's a dep for a Coq-related package I'm targetting. Cheers, J.Puydt
Bug#1019692: ITP: mathcomp-abel -- Abel-Galois and Abel-Ruffini theorems for Mathematical Components
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Julien Puydt X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org Severity: wishlist * Package name: mathcomp-abel Version : 1.2.1 Upstream Author : Sophie Bernard, Cyril Cohen, Assia Mahboubi, Pierre-Yves Strub * URL : https://github.com/math-comp/Abel * License : CeCILL-B Programming Lang: Coq Description : Abel-Galois and Abel-Ruffini theorems for Mathematical Components This package provides proofs of the Abel-Galois (solvability by radicals and solvability of the Galois group) and of the Abel-Ruffini theorem (general unsolvability of the quintic equations) using the Mathematical Components library. . The Mathematical Components library is a coherent repository of general-purpose formalized mathematical theories for the Coq proof assistant. I plan to support it within the Debian Ocaml Maintainers team, alongside the other Coq-related packages we have. 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#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#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)
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 à 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)
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)
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
Bug#1015044: Not a setuptools-scm issue?
Le lundi 05 septembre 2022 à 08:28 +1000, Brian May a écrit : > On Wed, Aug 03, 2022 at 12:22:32PM +0200, > julien.pu...@gmail.com wrote: > > I'm sorry, but I don't see why you think this is a problem with > > setuptools-scm. > > > > sshuttle's debian/rules asks setuptools-scm to generate a version > > file > > in its clean target. So setuptools-scm does so, and it doesn't look > > invalid. > > > > But it doesn't not correspond to the version file as shipped, so > > dpkg > > protests that the source tree has been modified. > > Please make sure you CC responses to me. Otherwise I won't get them. > > At first glance I thought this was invalid Python code, but oh wait, > I > think this is valid. Problem when dealing with too many languages. > > __version__ = version = '1.1.0' > __version_tuple__ = version_tuple = (1, 1, 0) > > But what seems to be the problem here is that setuptools-scm has > silently changed how it generates this file. Which breaks Debian > packages. > > If you don't agree with me, then assign this bug back to sshuttle and > I > will deal with it. In fact latest upstream sshuttle removes > setuptools-scm support anyway. If I remember well, that generation is done in the clean target: if that's the case, then it's sshuttle's (package's) problem. I see two solutions: - add a patch so the file becomes re-generation invariant ; - add an empty override_dh_whatever_clean in d/rules so the re- generation isn't triggered. 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#1004855: python3-ipykernel: missing dependency on debugpy
Le jeudi 11 août 2022 à 09:16 +0100, Julian Gilbey a écrit : > > And I thought it would be easy... It seems something in the > toolchain has changed since ipykernel was last built: it's now > including COPYING.md in the dist-info directory and lintian is > complaining about this. It's not obvious to me how to fix this in a > "nice" way. Any suggestions, or shall I ask on d-python? I know a few packages where debian/rules has: override_dh_auto_install: # usual install command, putting additional files/directories # pruning commands: find debian/tmp -name LICENSE -delete find debian/tmp -type d -empty -delete or some variants of it. Hope this helps, J.Puydt
Bug#1004855: python3-ipykernel: missing dependency on debugpy
Hi, Le mercredi 10 août 2022 à 20:32 +0100, Julian Gilbey a écrit : > > I'm happy to do this as a team upload, but equally happy if one of > you wants to (as the named Uploaders). If you have the commits at the ready, it's simpler for you to proceed. Thanks! 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#1016815: Updating proofgeneral to recent upstream
Package: proofgeneral Version: 4.4.1~pre170114-1.2 Severity: wishlist Hi, upstream released version 4.5 less than a month ago: https://github.com/ProofGeneral/PG/tags would it be possible to update the package? Thanks, 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#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#1015044: Not a setuptools-scm issue?
Hi, I'm sorry, but I don't see why you think this is a problem with setuptools-scm. sshuttle's debian/rules asks setuptools-scm to generate a version file in its clean target. So setuptools-scm does so, and it doesn't look invalid. But it doesn't not correspond to the version file as shipped, so dpkg protests that the source tree has been modified. Please reassign to the faulty package. Cheers, J.Puydt
