Bug#1073595: Missing symbols in the library file compared to the headers
Package: libuv1t64 Version: 1.48.0-4 Severity: serious Affects: ocaml-luv While updating the ocaml-luv package, I stumbled upon missing symbols for uv_wtf8_length_as_utf16, uv_wtf8_to_utf16, uv_utf16_length_as_wtf8 and uv_utf16_to_wtf8. After some poking around, they are declared in /usr/include/uv.h, but using objdump -T on /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0 doesn't show them. So it looks like there's something wrong with the libuv1t64 package. Cheers, J.Puydt
Bug#1073259: libyojson-ocaml-dev should depend on yojson-tools
Hi, Le samedi 15 juin 2024 à 16:43 +0200, Johannes Schauer Marin Rodrigues a écrit : > > Quoting Johannes Schauer Marin Rodrigues (2024-06-15 14:03:34) > > > > Julien, do you want to take care of that rebuild or should I? > Sorry I was away for most of the weekend, but yes, I didn't test my last change correctly and broke things. > I built them all using sbuild in unstable and found the following to > fail: > > botch: #1073199 > coq-serapi: 1073269 > elpi: #1073275 > > Gianfranco just NMU-ed botch, so #1073199 should be taken care of. > Julien maintains elpi, so they probably can figure out how to fix > this. The build log of coq-serapi might indicate that something in > the last yojson upload (which included an upstream version bump) > broke it. Can you investigate? Thanks to Gianfranco for fixing botch. I just fixed elpi. I'll also take care of coq-serapi. This package is a problem - I wonder if I shouldn't have waited some more before packaging it: upstream is moving things around in different packages like crazy, so it's bound to break too often for my taste and my attention span. > In summary: I do not think that a Depends from the dev package on the > tools package is needed. Adrian, do you agree? Not needed! Cheers, JP
Bug#1073162: marked as pending in yojson
Control: tag -1 pending Hello, Bug #1073162 in yojson reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ocaml-team/yojson/-/commit/0b97f0bcdba536ebd55ffe5d62d3c3dc54e9962c Add missing Breaks+Replaces for the new package (Closes: #1073162) (this message was generated automatically) -- Greetings https://bugs.debian.org/1073162
Bug#1064694: marked as pending in terminado
Control: tag -1 pending Hello, Bug #1064694 in terminado reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/terminado/-/commit/bd92e5a9dd4cac0c05211aef5e0ed4113de4fb69 Notice a bug is closed by new version (Closes: #1064694) (this message was generated automatically) -- Greetings https://bugs.debian.org/1064694
Bug#1070787: coq-corn: produces empty binary
Hi, Le jeudi 09 mai 2024 à 09:45 +0200, Gianfranco Costamagna a écrit : > Source: coq-corn > Version: 8.19.0-1 > Severity: serious > > Hello, looks like there are at least two issues: > 1) fta directory was stripped on tarball import, not sure how and > why, because the upstream repo still contains it > (this makes autopkgtest fail) > > 2) the produced binary package looks empty > > https://packages.debian.org/sid/amd64/libcoq-corn/filelist > /usr/share/doc/libcoq-corn/changelog.Debian.gz > /usr/share/doc/libcoq-corn/copyright > /var/lib/coq/md5sums/libcoq-corn.checksum > > For sure changes in configure.sh are a possible culprit What happened? I ran "uscan -v" in my ~/Debian/ocaml/ directory. At one point coq- corn's tarball got downloaded as 8.19.0.tar.gz and symlinked to coq- corn_8.19.0.tar.gz ; then later coq-math-classes' tarball got downloaded as 8.19.0.tar.gz and symlinked to coq-math- classes_8.19.0.tar.gz (they use the same version as the latest Coq they target...). The end result is that the final 8.19.0.tar.gz was really the coq-math- classes tarball, but there were two symlinks to it! So when I imported the tarballs (gbp import-orig ../correct-package-source- name_8.19.0.tar.gz) and updated the packages, I ended up with the wrong sources in the coq-corn directory! And since the Debian packages for both look pretty much the same, I didn't notice anything amiss when compiling. That is really stupid ; perhaps I should file a bug report against uscan because it's a sort of race condition... In any case, thanks for the report, I'll fix the mess! Cheers, J.Puydt
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#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#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#1055732: marked as pending in fpylll
Control: tag -1 pending Hello, Bug #1055732 in fpylll reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/fpylll/-/commit/445831e9a82bbf938e181c7b890dff0b9723 Package new upstream 0.6.0 (Closes: #1055732, #1056800) (this message was generated automatically) -- Greetings https://bugs.debian.org/1055732
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#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#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#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#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#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#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#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#1023040: marked as pending in nbconvert
Control: tag -1 pending Hello, Bug #1023040 in nbconvert reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/nbconvert/-/commit/b4c941de7855087e9ee2ec5488428432bbd7f61f Add 0008-dont-use-intersphinx-during-build.patch Building documentation with Sphinx uses intersphinx by default, which downloads data from the internet. This isn't allowed during Debian binary builds. Closes: #1023040 (this message was generated automatically) -- Greetings https://bugs.debian.org/1023040
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#1018228: marked as pending in jupyterlab-pygments
Control: tag -1 pending Hello, Bug #1018228 in jupyterlab-pygments reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/jupyterlab-pygments/-/commit/a1214fa4ffcaf497370c7af35c9cf7b0cc0a9aac Fix autopkgtest dependencies (Closes: #1018228) (this message was generated automatically) -- Greetings https://bugs.debian.org/1018228
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
Bug#1013362: marked as pending in alt-ergo
Control: tag -1 pending Hello, Bug #1013362 in alt-ergo reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ocaml-team/alt-ergo/-/commit/605e7a1e687fe1afa5a0e0b0b35ce8677f304062 Add conditional patch for non-native architectures (Closes: #1013362) (this message was generated automatically) -- Greetings https://bugs.debian.org/1013362
Bug#1011964: marked as pending in ipykernel
Control: tag -1 pending Hello, Bug #1011964 in ipykernel reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/ipykernel/-/commit/db93b2b4ba526c756039655a4d65e45b3447be88 Unbreak the compilation (Closes: #1011964) (this message was generated automatically) -- Greetings https://bugs.debian.org/1011964
Bug#1012224: It's a curl issue actually
Hi, it is in fact a curl issue : https://bugs.launchpad.net/ubuntu/+source/python-tornado/+bug/1975527 This report is a duplicate of #1011696. I thought I had already reported to the curl maintainers, but the corresponding curl bug is #1012263, very recent and hasn't the right priority. Cheers, J.Puydt
Bug#1010822: marked as pending in jupyter-client
Control: tag -1 pending Hello, Bug #1010822 in jupyter-client reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/jupyter-client/-/commit/9b527c4fd171277afd25f62b9e119a1162c655fb Add version dependency on python3-pytest-asyncio also in d/tests/control (Closes: #1010822) (this message was generated automatically) -- Greetings https://bugs.debian.org/1010822
Bug#1006816: marked as pending in python-anyio
Control: tag -1 pending Hello, Bug #1006816 in python-anyio reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-anyio/-/commit/76fdf6c58cef46d10821a4adef08467b2ce6ae3d Apply Gianfranco Costamagna's patch (Closes: #1006816) (this message was generated automatically) -- Greetings https://bugs.debian.org/1006816
Bug#1000271: marked as pending in jupyter-client
Control: tag -1 pending Hello, Bug #1000271 in jupyter-client reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/jupyter-client/-/commit/9b99a7b77dc73f3cd288dcc191b75a400b031079 Checked dask.distributed builds with this (Closes: #1000271) (this message was generated automatically) -- Greetings https://bugs.debian.org/1000271
Bug#1009055: Just crashes
Package: pitivi
Version: 2021.05-1
Severity: grave
Just launching it after install gives:
Missing soft dependency:
- GSound not found on the system
-> enables sound notifications when rendering is complete
Traceback (most recent call last):
File "/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/application.py",
line 135, in do_startup
loggable.init('PITIVI_DEBUG', enable_color, enable_crack_output)
File "/usr/lib/x86_64-linux-
gnu/pitivi/python/pitivi/utils/loggable.py", line 651, in init
add_limited_log_handler(print_handler)
File "/usr/lib/x86_64-linux-
gnu/pitivi/python/pitivi/utils/loggable.py", line 738, in
add_limited_log_handler
if not isinstance(func, collections.Callable):
AttributeError: module 'collections' has no attribute 'Callable'
Traceback (most recent call last):
File "/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/application.py",
line 203, in do_activate
self.create_main_window()
File "/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/application.py",
line 209, in create_main_window
self.gui = MainWindow(self)
File "/usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/mainwindow.py",
line 108, in __init__
self.app.settings.connect("useDarkThemeChanged",
AttributeError: 'NoneType' object has no attribute 'connect'
Cheers,
J.Puydt
Bug#1009054: Just crashes
Package: openshot-qt
Version: 2.6.1+dfsg1-1
Severity: grave
I just installed the software, launched "openshot-qt" and got a crash.
I'll put the result of "openshot-qt 2>&1 |tee /tmp/log" at the end of
this mail.
Cheers,
J.Puydt
Here is /tmp/log:
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
QT_QPA_PLATFORM=wayland to run on Wayland anyway.
INFO app:
INFO app: Wed Apr 6 17:13:25 2022
INFO app: Starting new session
INFO app:
INFO app: OpenShot (version 2.6.1)
INFO app:
INFO app: openshot-qt version: 2.6.1
INFO app: libopenshot version: 0.2.7
INFO app: platform: Linux-5.16.0-4-amd64-x86_64-with-glibc2.33
INFO app: processor:
INFO app: machine: x86_64
INFO app: python version: 3.10.4
INFO app: qt5 version: 5.15.2
INFO app: pyqt5 version: 5.15.6
INFO project_data: Setting default profile to HD 720p 30 fps
INFO language: Qt Detected Languages: ['fr-FR']
INFO language: LANG Environment Variable: fr_FR.UTF-8
INFO language: LOCALE Environment Variable:
INFO language: OpenShot Preference Language: Default
INFO app: Setting font to Cantarell
INFO logger_libopenshot: Connecting to libopenshot with debug port:
5556
INFO app: Setting custom dark theme
INFO ui_util: Initializing UI for MainWindow
INFO webkit: WebKit backend initializing
INFO thumbnail: Starting thumbnail server listening on port 55351
INFO transition_model: updating transitions model.
INFO effects_model: updating effects model.
INFO emoji_model: updating emoji model.
INFO version: Found current version: {'error_rate_stable': 0.16,
'trans_rate_unstable': 0.001, 'error_rate_unstable': 0.05,
'trans_rate_stable': 0.01, 'openshot_version': '2.6.1'}
INFO main_window: InitCacheSettings
INFO main_window: cache-mode: CacheMemory
INFO main_window: cache-limit-mb: 250
INFO main_window: Creating CacheMemory object with 262144000 byte limit
INFO preview_thread: QThread Start Method Invoked
ERROR main_window: Unhandled crash detected: linux-/lib/x86_64-linux-
gnu/libc.so.6 abort 0x112 [0x7ff285404546]
INFO main_window: updateStatusChanged
INFO main_window: recover_backup
INFO project_data: Setting default profile to HD 720p 30 fps
INFO preview_thread: player Position(): 1
INFO video_widget: Load: Set video widget display aspect ratio to:
1.777910232544
INFO video_widget: Set video widget pixel aspect ratio to: 1.0
INFO main_window: updateStatusChanged
INFO webkit: Registering objects with WebKit
qt.svg: Invalid path data; path truncated.
qt.svg: Invalid path data; path truncated.
qt.svg: Invalid path data; path truncated.
Unhandled Python exception
Caught signal 6 (SIGABRT)
Unhandled Exception: Stack Trace
/lib/x86_64-linux-gnu/libc.so.6 ( abort
+ 0x112 ) [0x7f199f905546]
/lib/x86_64-linux-gnu/libQt5Core.so.5 (
+ 0x90b51) [0x7f199e6d6b51]
/usr/lib/python3/dist-packages/PyQt5/QtCore.abi3.so (
+ 0xb5237) [0x7f199ec4b237]
/usr/lib/python3/dist-packages/PyQt5/sip.cpython-310-x86_64-linux-
gnu.so ( + 0x11363)
[0x7f199c0d8363]
/usr/lib/python3/dist-packages/PyQt5/QtWidgets.abi3.so (
+ 0x154b1d) [0x7f199bcc0b1d]
/usr/lib/python3/dist-packages/PyQt5/QtWidgets.abi3.so (
+ 0x3a581c) [0x7f199bf1181c]
/lib/x86_64-linux-gnu/libQt5Widgets.so.5 ( QWidget::event(QEvent*)
+ 0x20e ) [0x7f199b6674ce]
/usr/lib/python3/dist-packages/PyQt5/QtWidgets.abi3.so (
+ 0x3ac443) [0x7f199bf18443]
/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 0x7f )
[0x7f199b6256bf]
/usr/lib/python3/dist-packages/PyQt5/QtWidgets.abi3.so (
+ 0x3bd8ae) [0x7f199bf298ae]
/lib/x86_64-linux-gnu/libQt5Core.so.5 (
QCoreApplication::notifyInternal2(QObject*, QEvent*) + 0x12a )
[0x7f199e8f5aba]
/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (
QWidgetPrivate::sendPaintEvent(QRegion const&) + 0x36 )
[0x7f199b65f516]
/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (
QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint
const&, QFlags, QPainter*,
QWidgetRepaintManager*) + 0x7d2 ) [0x7f199b65fd42]
/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (
QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList
const&, int, QRegion const&, QPoint const&,
QFlags, QPainter*,
QWidgetRepaintManager*) + 0x4f0 ) [0x7f199b661180]
/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (
QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint
const&, QFlags, QPainter*,
QWidgetRepaintManager*) + 0x4ec ) [0x7f199b65fa5c]
/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (
QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList
const&, int, QRegion const&, QPoint const&,
QFlags, QPainter*,
QWidgetRepaintManager*) + 0x4f0 ) [0x7f199b661180]
Bug#1008514: FTBFS -- upstream test suite failure
Package: node-immutable Version: 4.0.0-2 Severity: serious Tags: ftbfs Trying to build the package in an unstable sbuild, I get the following failure: + NODE_PATH=node_modules:/usr/share/nodejs jest --ci __tests__/ArraySeq.ts Error at Function.missingTransform (/usr/share/nodejs/buble/dist/buble.cjs.js:367:9) at Node.initialise (/usr/share/nodejs/buble/dist/buble.cjs.js:2650:17) at Node.initialise (/usr/share/nodejs/buble/dist/buble.cjs.js:105:11) at /usr/share/nodejs/buble/dist/buble.cjs.js:103:40 at Array.forEach () at Node.initialise (/usr/share/nodejs/buble/dist/buble.cjs.js:103:11) at Node.initialise (/usr/share/nodejs/buble/dist/buble.cjs.js:105:11) at Node.initialise (/usr/share/nodejs/buble/dist/buble.cjs.js:2118:9) at /usr/share/nodejs/buble/dist/buble.cjs.js:795:34 dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1 Cheers, J.Puydt
Bug#1008513: FTBFS unsufficient coverage
Package: node-ignore Version: 5.2.0-1 Severity: serious Tags: ftbfs Building the package in an unstable sbuild, I get: ERROR: Coverage for lines (92.3%) does not meet global threshold (100%) ERROR: Coverage for functions (91.66%) does not meet global threshold (100%) ERROR: Coverage for branches (87.65%) does not meet global threshold (100%) ERROR: Coverage for statements (92.08%) does not meet global threshold (100%) --|-|--|-|-|--- -- File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s --|-|--|-|-|--- -- All files | 92.08 |87.65 | 91.66 |92.3 | index.js | 92.08 |87.65 | 91.66 |92.3 | 364,369,377,382- 383,419-421,562,569 --|-|--|-|-|--- -- Cheers, J.Puydt
Bug#1008512: FTBFS in upstream test suite
Package: node-https-proxy-agent Version: 5.0.0+~cs8.0.0-3 Severity: serious Tags: ftbfs Trying to rebuild the package in an unstable sbuild gives the following failure in upstream test suite: 1) HttpsProxyAgent "http" module should receive the 407 authorization code on the `http.ClientResponse`: Uncaught Error [ERR_SOCKET_CLOSED]: Socket is closed at new NodeError (internal/errors.js:322:7) at Socket._writeGeneric (net.js:789:8) at Socket._write (net.js:811:8) at doWrite (internal/streams/writable.js:377:12) at clearBuffer (internal/streams/writable.js:529:7) at Socket.Writable.uncork (internal/streams/writable.js:317:7) at ClientRequest._flushOutput (_http_outgoing.js:935:10) at ClientRequest._flush (_http_outgoing.js:904:22) at onSocketNT (_http_client.js:824:9) at processTicksAndRejections (internal/process/task_queues.js:83:21) Cheers, J.Puydt
Bug#1008511: FTBFS failures in the upstream test suite
Package: node-configurable-http-proxy Version: 4.5.0+~cs15.1.4-3 Severity: serious Tags: ftbfs Building the package in an unstable sbuild, I get failures: Randomized with seed 97263 Started ..F...06:23:50.587 [ConfigProxy] ESC[31merrorESC[39m: 404 GET /nope 06:23:50.860 [ConfigProxy] ESC[31merrorESC[39m: 503 GET /missing/prefix connect ECONNREFUSED 127.0.0.1:54321 ...06:23:50.953 [ConfigProxy] ESC[31merrorESC[39m: 404 GET /nope 06:23:51.227 [ConfigProxy] ESC[31merrorESC[39m: 503 GET /missing/prefix connect ECONNREFUSED 127.0.0.1:54321 .06:23:51.270 [ConfigProxy] ESC[31merrorESC[39m: 503 GET /missing/prefix connect ECONNREFUSED 127.0.0.1:54321 06:23:51.273 [ConfigProxy] ESC[31merrorESC[39m: 503 GET /missing/ws connect ECONNREFUSED 127.0.0.1:54321 ...06:23:51.346 [ConfigProxy] ESC[31merrorESC[39m: 404 GET /foo/bar ...06:23:51.370 [ConfigProxy] ESC[31merrorESC[39m: 500 GET /% URIError: URI malformed at decodeURIComponent () at ConfigurableProxy.targetForReq (/<>/lib/configproxy.js:385:27) at ConfigurableProxy.handleProxy (/<>/lib/configproxy.js:529:17) at ConfigurableProxy.handleProxyWeb (/<>/lib/configproxy.js:613:17) at Server. (/<>/lib/configproxy.js:198:27) at Server.emit (events.js:400:28) at parserOnIncoming (_http_server.js:900:12) at HTTPParser.parserOnHeadersComplete (_http_common.js:127:17) .06:23:51.403 [ConfigProxy] ESC[32minfoESC[39m: Adding route / -> http://127.0.0.1:9001 06:23:51.403 [ConfigProxy] ESC[32minfoESC[39m: Route added / -> http://127.0.0.1:9001 . Failures: 1) CLI Tests custom-header Message: Error: Timeout - Async function did not complete within 1ms (set by jasmine.DEFAULT_TIMEOUT_INTERVAL) Stack: at at listOnTimeout (internal/timers.js:557:17) at processTimers (internal/timers.js:500:7) Message: Error: Timeout - Async function did not complete within 1ms (set by jasmine.DEFAULT_TIMEOUT_INTERVAL) Stack: at at listOnTimeout (internal/timers.js:557:17) at processTimers (internal/timers.js:500:7) 58 specs, 1 failure Cheers, J.Puydt
Bug#1008510: FTBFS unsufficient coverage
Package: node-base64url Version: 3.0.1-7 Severity: serious Tags: ftbfs Trying to build the package in an unstable sbuild, the upstream test suite fails because it doesn't find a 100% coverage: ERROR: Coverage for lines (97.22%) does not meet global threshold (100%) ERROR: Coverage for branches (75%) does not meet global threshold (100%) ERROR: Coverage for statements (94.73%) does not meet global threshold (100%) ---|-|--|-|-|-- - File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s ---|-|--|-|-|-- - All files | 94.73 | 75 | 100 | 97.22 | node-base64url-3.0.1 | 100 | 100 | 100 | 100 | index.js | 100 | 100 | 100 | 100 | node-base64url-3.0.1/dist | 94.44 | 75 | 100 | 97.05 | base64url.js | 95.23 |83.33 | 100 | 100 | 13 pad-string.js| 93.33 | 50 | 100 | 93.33 | 8 ---|-|--|-|-|-- - Cheers, J.Puydt
Bug#1008509: FTBFS - six upstream tests failing
Package: node-config Version: 3.3.7-1 Severity: serious Tags: ftbfs While rebuilding your package with an unstable sbuild, it failed at six points in the upstream test suite, with the same error: » An unexpected error was caught: TypeError: Cannot set property offset of [object Object] which has only a getter Cheers, J.Puydt
Bug#1006816: Forwarded upstream
Hi, I forwarded the bug to upstream: https://github.com/agronholm/anyio/issues/417 Here is the commit upstream would like feedback about: https://github.com/agronholm/anyio/commit/184744ca291d426dd278f697c3637623eb9de0ed Can you check? Thanks! J.Puydt
Bug#1005920: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#1005920: fixed in coq-doc 8.15.0-3)
Hi, Le mercredi 23 février 2022 à 13:21 +0100, Andreas Beckmann a écrit : > With all these B-D added, the build fails for me now with > > Not sure what exactly causes the failure ... It's an heisenbug: - I added a patch to get more log ; - I tried to build the package: success ; - I tried again: failure. Cheers, J.Puydt
Bug#1005920: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#1005920: fixed in coq-doc 8.15.0-3)
Le mercredi 23 février 2022 à 13:21 +0100, Andreas Beckmann a écrit : > With all these B-D added, the build fails for me now with > > Running[3870]: (cd _build/default/doc && /usr/bin/env sphinx-build -q > -W -b html sphinx refman-html) > Command [3870] exited with code 2: > $ (cd _build/default/doc && /usr/bin/env sphinx-build -q -W -b html > sphinx refman-html) > > Warning, treated as error: > /build/coq-doc-8.15.0/_build/default/doc/sphinx/index.rst:45:toctree > contains reference to document 'zebibliography' that doesn't have a > title: no link will be generated > ANTLR runtime and generated code versions disagree: 4.9.1!=4.7.2 > Duplicate cmd name: Extraction > Duplicate exn name: Not equal > Duplicate exn name: Not equal (due to universes) > Duplicate tacn name: first (ssreflect) > Duplicate tacn name: have > Duplicate tacn name: move (ssreflect) > Duplicate tacn name: apply (ssreflect) > Duplicate tacn name: under > Duplicate tacn name: over > Duplicate tacn name: wlog > Duplicate tacn name: set (ssreflect) > Duplicate tacn name: unlock > Duplicate tacn name: congr > Duplicate cmd name: Hint View for apply > Duplicate cmd name: Prenex Implicits > Duplicate exn name: Not the right number of missing arguments > Duplicate exn name: No such hypothesis in current goal > Duplicate exn name: No such hypothesis > Duplicate exn name: ‘ident’ is used in the hypothesis ‘ident’ > Duplicate exn name: No such hypothesis > Duplicate exn name: No such hypothesis > Duplicate exn name: ‘ident’ is already used > Duplicate exn name: No such assumption > Duplicate exn name: No focused proof (No proof-editing in progress) > Duplicate exn name: Not an inductive product > Duplicate exn name: No primitive equality found > > Not sure what exactly causes the failure ... I tested the package on barriere.debian.org and a local schroot before uploading, so I really don't get how that can fail. Those messages aren't the real problem, as I got them a lot even when the build succeeded. And indeed it can be hard to tell what the exact problem is: you have to take a look to CofRefMan.log and see what the complaints are about. Sometimes it was just a question of too many warnings... Guess what? Today, my local schroot fails, so I'll probably be able to do something... again. I admit that bug is stubborn: I already closed it twice and it's still kicking. But I'll get it in the end. J.Puydt
Bug#1005920: marked as pending in coq-doc
Control: tag -1 pending Hello, Bug #1005920 in coq-doc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ocaml-team/coq-doc/-/commit/3008fb4bc49395c2ec746e6432b6198a46d9e48e Fix b-deps again (Closes: #1005920) (this message was generated automatically) -- Greetings https://bugs.debian.org/1005920
Bug#970453: coq-float looks dead upstream: RM?
Hi, I was looking around at all coq-related packages and found this poor thing, which seems pretty dead. I propose to ask for its removal ; I'll proceed in a few weeks if nobody objects. Cheers, J.Puydt
Bug#1005920: marked as pending in coq-doc
Control: tag -1 pending Hello, Bug #1005920 in coq-doc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ocaml-team/coq-doc/-/commit/d5b32b6c0fe472dc5ab16bae202016df9bc6928e Fix b-deps (Closes: #1005920) (this message was generated automatically) -- Greetings https://bugs.debian.org/1005920
Bug#1005852: marked as pending in ssreflect
Control: tag -1 pending Hello, Bug #1005852 in ssreflect reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ocaml-team/ssreflect/-/commit/ec4a6dfe346919f082e2621a58b58230e6d1ddf0 Better for for Breaks+Replaces (Closes: #1005852) (this message was generated automatically) -- Greetings https://bugs.debian.org/1005852
Bug#1005287: [Pkg-javascript-devel] Bug#1005287: node-csstype: Build drops "; " in typescript declarations
Le jeudi 10 février 2022 à 16:20 +0100, Yadd a écrit : > On 10/02/2022 15:38, Yadd wrote: > > Package: node-csstype > > Version: 3.0.10-1 > > Severity: grave > > Justification: renders package unusable > > > > debian/rules launches `ts-node --files build.ts --start` which > > (only) > > modifies indes.d.ts and index.js.flow. The result is unusable with > > tsc: > > > > /usr/share/nodejs/csstype/index.d.ts:18305:8 - error TS1005: ';' > > expected. > > > > All final ";" are dropped. > > Removing override_dh_auto_build fixes the problem (using upstream > index.d.ts and index.js.flow which are readable) > > @Julien, could you take a look ? I think the problem is that in index.d.ts we have: export type SvgAttributes = export type Globals = while upstream has: export type SvgAttributes = export type Globals = so the missing ';' is a red herring: we don't get the SvgAttributes like we should, and that's the real problem. I see that debian/nodejs/extlinks does have mdn-browser-compat-data, but it creates node_modules/@mdn/browser-compat-data -- I don't know why it does that, but it's what's breaking things as far a I can tell. Do you know how to fix it? J.Puydt
Bug#1005254: marked as pending in ssreflect
Control: tag -1 pending Hello, Bug #1005254 in ssreflect reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ocaml-team/ssreflect/-/commit/135badc62bb84d96e58688788c419bd77039c84e Fix Breaks+Replaces (Closes: #1005254) (this message was generated automatically) -- Greetings https://bugs.debian.org/1005254
Bug#1003539: marked as pending in coq-doc
Control: tag -1 pending Hello, Bug #1003539 in coq-doc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ocaml-team/coq-doc/-/commit/0c53607b6e4b1c003bd669900a22af2049c3fc0d Package new upstream 8.15.0 (closes: #1003539) (this message was generated automatically) -- Greetings https://bugs.debian.org/1003539
Bug#1002988: Waiting for b-deps
Hi, now camlp5 8.* is in unstable the problem occurs ; I'm just waiting for the other b-deps to be available, but I have a commit ready. Cheers, J.Puydt
Bug#1002988: Too early to fix
Hi, upstream didn't release a new version with support for camlp5 8.* ; but they have a patch here: https://github.com/LPCIC/elpi/pull/110/commits/f58341831b56ccfe5f2f49158c600e4e36bcb9b5 so I should be able to fix the problem as soon as it actually occurs. Cheers, J.Puydt
Bug#1003797: marked as pending in ssreflect
Control: tag -1 pending Hello, Bug #1003797 in ssreflect reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ocaml-team/ssreflect/-/commit/6f28d0d38469c8c2ab1c7f6d757fee694b150296 Source-only upload to trigger a rebuild (Closes: #1003797) (this message was generated automatically) -- Greetings https://bugs.debian.org/1003797
Bug#1002745: marked as pending in minetest-mod-protector
Control: tag -1 pending Hello, Bug #1002745 in minetest-mod-protector reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/minetest-mod-protector/-/commit/2e4b937f0053889710879f3bfd72a80b7ac1cf2a Import correct upstream tarball (Closes: #1002745) (this message was generated automatically) -- Greetings https://bugs.debian.org/1002745
Bug#1002290: dh_python3 needing contextvars -- not a problem with my package, then?
Package: dh-python
Version: 5.20211217
Severity: grave
python-anyio package is supposedly broken (bug #1002179), but the build
log makes me think it's a problem with dh-python:
>dh_python3 -O--buildsystem=pybuild
> I: dh_python3 pydist:313: Cannot find package that provides
contextvars. Please add package that provides it to Build-Depends or
add "contextvars python3-contextvars" line to debian/py3dist-overrides
or add proper dependency to Depends by hand and ignore this info.
> Traceback (most recent call last):
> File "/usr/bin/dh_python3", line 280, in
> main()
> File "/usr/bin/dh_python3", line 201, in main
> dependencies.parse(stats, options)
> File "/usr/share/dh-python/dhpython/depends.py", line 242, in parse
> deps = parse_pydep(self.impl, fn, bdep=self.bdep,
**section_options)
> File "/usr/share/dh-python/dhpython/pydist.py", line 522, in
parse_pydep
> for part in dependency.split(','))
> AttributeError: 'NoneType' object has no attribute 'split'
> make: *** [debian/rules:8: binary] Error 1
Cheers,
J.Puydt
Bug#1002197: marked as pending in entrypoints
Control: tag -1 pending Hello, Bug #1002197 in entrypoints reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/entrypoints/-/commit/1282bdaf0febd9d4fa9a2b00a6c7e224af6054ee Add b-depends on python3-pytest (Closes: #1002197) (this message was generated automatically) -- Greetings https://bugs.debian.org/1002197
Bug#1000701: marked as pending in node-css-tree
Control: tag -1 pending Hello, Bug #1000701 in node-css-tree reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/js-team/node-css-tree/-/commit/fbb2270acc1a44f7915faeaf6076495623185bd8 Package upstream 1.1.3 (Closes: #1000701) (this message was generated automatically) -- Greetings https://bugs.debian.org/1000701
Bug#1000661: Missing b-dep on libbase64-ocaml-dev
Package: haxe Version: 1:4.1.5-1 Severity: grave I was checking whether a recent dune would break any package, and my test failed because Base64 was an unbound module -- it's a missing build-dep on libbase64-ocaml-dev, so it should be pretty straightforward to fix. Cheers, J.Puydt
Bug#1000573: Bytecode architectures blocking bug
Package: coq Version: 8.14.0+dfsg-6 Severity: grave X-Debbugs-CC: debian-ocaml-ma...@lists.debian.org Don't migrate to testing until the bytecode architectures' situation is cleared. Cheers, J. Puydt
Bug#1000365: Current pyzmq not playing well with Python 3.10 ?
Package: python3-zmq Version: 22.3.0-1 Severity: grave I have issues updating packages nbconvert and jupyterlab-server, both of which because of autopkgtest failures, with the similar-looking backtrace: autopkgtest [08:13:59]: test autodep8-python3: [--- Testing with python3.10: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/nbconvert/__init__.py", line 4, in from .exporters import * File "/usr/lib/python3/dist- packages/nbconvert/exporters/__init__.py", line 4, in from .slides import SlidesExporter File "/usr/lib/python3/dist-packages/nbconvert/exporters/slides.py", line 12, in from ..preprocessors.base import Preprocessor File "/usr/lib/python3/dist- packages/nbconvert/preprocessors/__init__.py", line 10, in from .execute import ExecutePreprocessor File "/usr/lib/python3/dist- packages/nbconvert/preprocessors/execute.py", line 8, in from nbclient import NotebookClient, execute as _execute File "/usr/lib/python3/dist-packages/nbclient/__init__.py", line 5, in from .client import NotebookClient, execute # noqa: F401 File "/usr/lib/python3/dist-packages/nbclient/client.py", line 21, in from jupyter_client import KernelManager File "/usr/lib/python3/dist-packages/jupyter_client/__init__.py", line 6, in from .asynchronous import AsyncKernelClient # noqa File "/usr/lib/python3/dist- packages/jupyter_client/asynchronous/__init__.py", line 1, in from .client import AsyncKernelClient # noqa File "/usr/lib/python3/dist- packages/jupyter_client/asynchronous/client.py", line 6, in from jupyter_client.channels import HBChannel File "/usr/lib/python3/dist-packages/jupyter_client/channels.py", line 12, in import zmq.asyncio File "/usr/lib/python3/dist-packages/zmq/__init__.py", line 103, in from zmq import backend File "/usr/lib/python3/dist-packages/zmq/backend/__init__.py", line 32, in raise original_error from None File "/usr/lib/python3/dist-packages/zmq/backend/__init__.py", line 27, in _ns = select_backend(first) File "/usr/lib/python3/dist-packages/zmq/backend/select.py", line 32, in select_backend mod = import_module(name) File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "/usr/lib/python3/dist-packages/zmq/backend/cython/__init__.py", line 6, in from . import ( ImportError: cannot import name 'constants' from partially initialized module 'zmq.backend.cython' (most likely due to a circular import) (/usr/lib/python3/dist-packages/zmq/backend/cython/__init__.py) autopkgtest [08:14:00]: test autodep8-python3: ---] The same error message is discussed here: https://github.com/zeromq/pyzmq/issues/1460 but it looks like the error message in fact hides the real issue... Cheers, J.Puydt
Bug#999651: marked as pending in coq
Control: tag -1 pending Hello, Bug #999651 in coq reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ocaml-team/coq/-/commit/8f166a65fea73b7ee1d8b2de0acf309d29e9d2c9 Disable the bytecode-only architectures (Closes: #999651) (this message was generated automatically) -- Greetings https://bugs.debian.org/999651
Bug#998712: marked as pending in irrlicht
Control: tag -1 pending Hello, Bug #998712 in irrlicht reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/irrlicht/-/commit/b681e14a0a1f3e41fa157c07058a051fdb51bffa Add comma between uploaders (Closes: #998712) (this message was generated automatically) -- Greetings https://bugs.debian.org/998712
Bug#997206: marked as pending in irrlicht
Control: tag -1 pending Hello, Bug #997206 in irrlicht reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/irrlicht/-/commit/a865607c5f63448aa7f6c9e88f87ca17450b5627 Shuffle patches around (closes: #997206) and update packaging (this message was generated automatically) -- Greetings https://bugs.debian.org/997206
Bug#984238: marked as pending in minetest
Control: tag -1 pending Hello, Bug #984238 in minetest reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/minetest/-/commit/4aa6170c45e922922110d441c7ce3b961e1e513b Add patch to fix compilation with gcc 11 (Closes: #984238) (this message was generated automatically) -- Greetings https://bugs.debian.org/984238
Bug#995185: Reported and fixed upstream
Hi, I reported upstream, a fix was found -- 2.21.1 should be out in a few days. Cheers, J.Puydt
Bug#995018: jupyterlab-server 2.4.0-1 broken by jupyter-server 1.10.2-1
Hi, I just tried to rebuild jupyterlab-server in my unstable sbuild, and could check that it used the jupyter-server you complain about, and passes the tests. I suspect the problem is that the latest version of python3-anyio doesn't migrate to testing (blocked by pytest). Cheers, J.Puydt
Bug#994545: Upstream bug
Hi, after more poking around, there were two issues: 1) the smaller one was that TypeScript >= 4.4 breaks upstream, but I could write a patch (and forward it) ; 2) the bigger one is that we need a more recent node-tslib, which is only in experimental at the moment, so I'm only uploading the fixed lumino to experimental too. Cheers, J.Puydt
Bug#994545: marked as pending in lumino
Control: tag -1 pending Hello, Bug #994545 in lumino reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/js-team/lumino/-/commit/1f8bef399778b0a12f5d2a4321f8747eed0f3c13 Add a patch to unbreak compilation with recent tsc (Closes: #994545) (this message was generated automatically) -- Greetings https://bugs.debian.org/994545
Bug#994545: Working on the problem
Hi, updating to a newer version will probably make that issue go away ; I'm expecting an answer to https://github.com/jupyterlab/lumino/issues/235 before going forward. Cheers, J.Puydt
Bug#994109: scilab FTBFS with hdf5 1.10.7
Hi Le dim. 12 sept. 2021 à 17:49, Gilles Filippini a écrit : > > Patch proposal attached. > Excellent! Please commit to salsa but don't upload yet: I have other things to do (though lacking time I might still end up uploading with only this). Thanks! J. Puydt >
Bug#993693: ReferenceError: options is not defined
Package: webpack Version: 5.6.0+~cs6.4.0-1~exp2 Severity: grave I was trying to update another js-team package and couldn't understand what was wrong until I tried to just run webpack by itself in another directory: $ webpack [webpack-cli] ReferenceError: options is not defined at Object.apply (/usr/share/nodejs/webpack/lib/config/defaults.js:873:30) at WebpackOptionsApply.process (/usr/share/nodejs/webpack/lib/WebpackOptionsApply.js:453:16) at createCompiler (/usr/share/nodejs/webpack/lib/webpack.js:78:28) at create (/usr/share/nodejs/webpack/lib/webpack.js:115:15) at webpack (/usr/share/nodejs/webpack/lib/webpack.js:123:46) at f (/usr/share/nodejs/webpack/lib/index.js:35:15) at WebpackCLI.createCompiler (/usr/share/nodejs/webpack- cli/lib/webpack-cli.js:176:24) at WebpackCLI.run (/usr/share/nodejs/webpack-cli/lib/webpack- cli.js:268:25) at async runCLI (/usr/share/nodejs/webpack- cli/lib/bootstrap.js:59:9) This means it's broken ; installing unstable's 4.43.0-6 made the error go away, so it's a problem only with the new version. Cheers, J.Puydt
Bug#993167: marked as pending in node-strip-json-comments
Control: tag -1 pending Hello, Bug #993167 in node-strip-json-comments reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/js-team/node-strip-json-comments/-/commit/4b54da3ae6c2a1dc83a362ab0726d6f4ed0a08a5 Drop the patch to stay require-able (Closes: #993167) (this message was generated automatically) -- Greetings https://bugs.debian.org/993167
Bug#993167: dont_be_a_module.patch is too dirty
Package: node-strip-json-comments Version: 4.0.0-1 Severity: serious I have to drop dont_be_a_module.patch ; it's too dirty. I'll do it later today, but still want to prevent any migration to testing. J.Puydt
Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found
Hi, Le mardi 08 juin 2021 à 14:58 +0200, Jochen Sprickerhof a écrit : > > friendly ping on the sagemath issue as it will be dropped from > testing > on the 18., otherwise. > As far as I read there are a number of proposals (downgrade, ignore > test > results..) besides fixing the tests. I'm happy to help with this but > leave it to the maintainers how to approach this. I've been convinced that getting a fragile sagemath in next stable wouldn't be a good thing. Cheers, JP
Bug#986527: Retitle to : Testsuite is too fragile - FTBFS randomly
retitle #986527 Testsuite is too fragile - FTBFS randomly thanks Now I get the point and I have to agree ; let me retitle this report so it states the actual problem. Cheers, JP
Bug#988654: marked as pending in node-es6-shim
Control: tag -1 pending Hello, Bug #988654 in node-es6-shim reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/js-team/node-es6-shim/-/commit/4d7f7022cee7b13716ef730ef6e572d3d687576c Fix broken symlinks (Closes: #988654) (this message was generated automatically) -- Greetings https://bugs.debian.org/988654
Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found
Hi, Le mardi 18 mai 2021 à 15:31 +0200, Jochen Sprickerhof a écrit : > > * Julien Puydt [2021-05-18 07:56]: > > 1) Upstream itself uses the testsuite in the sense of "shouldn't > > have > > too many failing tests", and it still allows to detect when a build > > is > > utterly broken, so we shouldn't disable it. > > Debian doesn't necessarily need to do the same as upstream here. Upstream manages to ship version with no error because they ship hundreds of deps to an exact version for which they fitted the testsuite to pass. We ship those deps as separate packages, because they're actually not sagemath-specific [look at the list, it's pretty telling : https://people.debian.org/~thansen/debian-sage-status.html ], so we might not have the exact same version, and that's enough to trigger artificial failures. I don't think we'll ever hit zero. At least not while their testsuite framework is so... so like it is. If we keep it with an allowed error rate, we detect the package is *really* broken before shipping ; if we don't, we detect it is broken after shipping, because it hurts the users and they complain. Sagemath is definitely not bug-free, the Debian package for it isn't bug-free either, but it is working and useful to users, and this (bringing useful software to users) is what Debian is about. If I look at the title of this bug, I think "Oh, just patch src/bin/sage so it calls cython3 and not cython" (see my message #20), but if you look at the exchange, then it's not clear at all what the problem actually is. The buildd logs ( https://buildd.debian.org/status/package.php?p=sagemath=bullseye ), John Cross (message #10), myself (message #25) and the triggered RB rebuild (message #30) all conclude the package doesn't FTBFS. I would like to fix the problem, but at that point, I have no clue what it really is about... JP
Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found
Hi, Le lundi 17 mai 2021 à 15:20 +0200, Jochen Sprickerhof a écrit : > Hi Julien, > > * Julien Puydt [2021-05-17 09:01]: > > I tried to create a testing sbuild and compile sagemath 9.2-2 with > > it, > > and it worked so unless I made a mistake in my setup, something > > made > > that bug go away... > > > > Can someone independently give it a try? > > I triggered reproducible-builds again: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sagemath.html > > Success: 40 tests failed, up to 200 failures are tolerated > Success: 5 tests failed, up to 200 failures are tolerated > > so not much changed comparing to two weeks ago and my conclusion > still > holds: > > * Jochen Sprickerhof [2021-05-04 13:22]: > > Success: 41 tests failed, up to 200 failures are tolerated > > Success: 5 tests failed, up to 200 failures are tolerated > > > > The 200 is set in debian/rules: > > > > https://salsa.debian.org/science-team/sagemath/-/commit/6088e9f2abc7ae99a8d07760ceee6fb6aac7bb54 > > > > and sounds a little arbitrary. Sadly the state upstream seems not > > to > > be much better: > > > > https://github.com/sagemath/sage/tree/9.2 > > > > 13 failing, 17 cancelled, and 70 successful checks > > > > (I did not look into them.) > > > > So I think the question is rather if the test suite gives an > > appropriate view on the quality of the software. If it does, I > > assume > > it is not appropriate for a Debian stable release. Contrary if we > > assume the test suite being broken, we could disable it completely > > rather then producing random FTBFS. Well : 1) Upstream itself uses the testsuite in the sense of "shouldn't have too many failing tests", and it still allows to detect when a build is utterly broken, so we shouldn't disable it. 2) It's not an FTBFS, since the sources actually build to a set of packages. This points to lowering this bug severity and let sagemath go in stable. Or at least not preventing it just for this reason. JP
Bug#986527: Please check again : outdated report?
Hi, I tried to create a testing sbuild and compile sagemath 9.2-2 with it, and it worked so unless I made a mistake in my setup, something made that bug go away... Can someone independently give it a try? JP
Bug#986527: It's a build-dep issue
Hi, I had a look: - sagemath build-depends on cython3 - /usr/bin/cython is in cython - /usr/bin/cython3 is in cython3 so I see two ways out : (1) change the b-dep to cython (from cython3) [and cython-dbg from cython3-dbg, I guess] ; (2) make so cython is called as cython3. I can't give it a try before at least a week, so if someone wants to dive in... JP
Bug#976778: marked as pending in fpylll
Control: tag -1 pending Hello, Bug #976778 in fpylll reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/fpylll/-/commit/dbeb1da4297e5786d31a9c509f439cbfb08e8d6e Add patch from upstream (Closes: #976778) (this message was generated automatically) -- Greetings https://bugs.debian.org/976778
Bug#976619: marked as pending in ts-node
Control: tag -1 pending Hello, Bug #976619 in ts-node reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/js-team/ts-node/-/commit/79aeb9d5e76194d8153cc23fdc010b4c443f2822 Add runtime dependencies (Closes: #976619) (this message was generated automatically) -- Greetings https://bugs.debian.org/976619
Bug#976995: Error importing plugin "pytest_tornasync": No module named 'pytest_tornasync'
Package: python3-pytest
Version: 4.6.11-1
Severity: grave
I was trying to update another package in the Debian Python Team, and
couldn't understand why its testsuite failed with the above error.
After some failed poking around, I put the following in a file named
test_foo.py:
def test_foo():
pass
and ran 'pytest-3 test_foo.py' : same error. So I think the problem is
with python3-pytest and not with the original package.
I'm setting the severity to grave since it makes the package unusable.
Cheers,
JP
PS: the full trace is:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 572, in import_plugin
__import__(importspec)
ModuleNotFoundError: No module named 'pytest_tornasync'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/pytest-3", line 11, in
load_entry_point('pytest==4.6.11', 'console_scripts', 'pytest')()
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 65, in main
config = _prepareconfig(args, plugins)
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 213, in _prepareconfig
return pluginmanager.hook.pytest_cmdline_parse(
File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286, in
__call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92, in
_hookexec
return self._inner_hookexec(hook, methods, kwargs)
File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83, in
self._inner_hookexec = lambda hook, methods, kwargs:
hook.multicall(
File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 203, in
_multicall
gen.send(outcome)
File "/usr/lib/python3/dist-packages/_pytest/helpconfig.py", line 94,
in pytest_cmdline_parse
config = outcome.get_result()
File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in
get_result
raise ex[1].with_traceback(ex[2])
File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in
_multicall
res = hook_impl.function(*args)
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 789, in pytest_cmdline_parse
self.parse(args)
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 997, in parse
self._preparse(args, addopts=addopts)
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 943, in _preparse
self.pluginmanager.load_setuptools_entrypoints("pytest11")
File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 298, in
load_setuptools_entrypoints
self.register(plugin, name=ep.name)
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 335, in register
self.consider_module(plugin)
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 540, in consider_module
self._import_plugin_specs(getattr(mod, "pytest_plugins", []))
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 545, in _import_plugin_specs
self.import_plugin(import_spec)
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 581, in import_plugin
six.reraise(ImportError, new_exc, tb)
File "/usr/lib/python3/dist-packages/six.py", line 702, in reraise
raise value.with_traceback(tb)
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 572, in import_plugin
__import__(importspec)
ImportError: Error importing plugin "pytest_tornasync": No module named
'pytest_tornasync'
Bug#976778: Known upstream, fixed with upcoming new version
Hi, here is the upstream patch fixing the issue : https://github.com/fplll/fpylll/commit/ede1e459f0662a0940dca6366aba20d47183a4a0 I tought they'd have already released the new version with this in, but I should have waited until that was done... And since this patch needs other changes to apply, I can't just add it. I'll work on it as soon as upstream will have released the new version. Sorry, JP
Bug#975241: marked as pending in terminado
Control: tag -1 pending Hello, Bug #975241 in terminado reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/terminado/-/commit/6ebf175a8c93d92b9b173ac2de85763acf4894f0 Add trivial patch (Closes: #975241) (this message was generated automatically) -- Greetings https://bugs.debian.org/975241
Bug#971902: Don't upload scilab
Hi, please push your commit but don't upload : - I'll report upstream and forward your patch ; - I'll take the occasion to do some little things on the package, so I'll upload when I'll be done (probably before next monday). Thanks! JP
Bug#973588: Update from pari 2.11 to 2.13 breaks giac compilation
Le jeudi 05 novembre 2020 à 19:12 +0100, Bill Allombert a écrit : > On Mon, Nov 02, 2020 at 09:57:07AM +0100, Bill Allombert wrote: > > This means 512000 is not sufficient. This is a fatal error. > > The test cannot pass. > > Would you mind uploading giac with PARI_SIZE=1024000 so that we can > close this bug ? I have done that, but still, crashing is pretty bad : it should detect the value is too low at startup and complain. JP
Bug#973588: Update from pari 2.11 to 2.13 breaks giac compilation
Package: libpari-dev
Version: 2.13.0-2
Severity: grave
The last pari upload broke giac on amd64, arm64 and mipsel :
https://buildd.debian.org/status/fetch.php?pkg=giac=amd64=1.6.0.25%2Bdfsg1-2%2Bb1=1604135053=0
The failing test on amd64 is a segfault. I could check that running the
failing test by hand while exporting PARI_SIZE=1024000 makes the
problem disappear, and PARI_SIZE=512000 or nothing makes it come back ;
here is an abstract from giac's pari.cc:
static struct pari_constants_initialization {
pari_constants_initialization () {
if (getenv("PARI_SIZE")){
string pari_size_s(getenv("PARI_SIZE"));
pari_mem_size= atoi(pari_size_s.c_str());
}
entree * ptr=functions_basic;
for (;ptr->name;++ptr){
pari_function_table[ptr->name]=ptr;
}
}
} pari_constants_initialization_singleton;
static void call_pari_init()
{
// do not initialize INIT_JMP so that PARI error do not exit
pari_init_opts(pari_mem_size,pari_maxprime,INIT_SIGm | INIT_DFTm);
paristack_setsize(pari_mem_size, (1<<30));
// initialize variable ordering x,y,z
gp_read_str("[x,y,z,t]");
}
Since it worked with pari 2.11 and breaks with pari 2.13, I guess the
problem is on pari's side.
Setting severity to grave because it breaks another package.
I hope it helps,
JP
Bug#971108: marked as pending in python-tornado
Control: tag -1 pending Hello, Bug #971108 in python-tornado reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-tornado/-/commit/8376c014401ceed012df0a329f95782813981bfb Add upstream patch (Closes: #971108) (this message was generated automatically) -- Greetings https://bugs.debian.org/971108
Bug#957229: marked as pending in freedroidrpg
Control: tag -1 pending Hello, Bug #957229 in freedroidrpg reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/freedroidrpg/-/commit/93503e642cdc4fee3e814b948cabf2a92075c5c2 Add patch for gcc 10 support (Closes: #957229) (this message was generated automatically) -- Greetings https://bugs.debian.org/957229
Bug#967209: rgtk2: Unversioned Python removal in sid/bullseye
Hi, Le mardi 04 août 2020 à 07:49 -0500, Dirk Eddelbuettel a écrit : > Hi doko and Python folks, > > I am lost. > I suggest to check the shebangs. Cheers, JP
Bug#966321: Python 2 dep in mnemosyne : where does it come from?
Hi, I just had a look in d/control, and didn't see where the Python 2 dep could come from... If you have a clue, that would help... JP
Bug#966321: mnemosyne: Python2 removal in sid/bullseye
Hi Le dim. 26 juil. 2020 à 20:15, Sandro Tosi a écrit : > Source: mnemosyne > Version: 2.7.2+ds1-1 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > I'll take care of this next week. Cheers, JP >
Bug#964109: Already reported upstream
Hi, I reported the issue to upstream 11 days ago : https://github.com/wbhart/flint2/issues/771 JP
