Bug#1068498: new upstream version 4.0.2
Source: xeus Severity: wishlist Dear Xeus maintainers, There is a new major upstream release available (4.0.2). Do you plan to package it ? Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1060164: libxeus9 incompatible with nlohmann::json_abi_v3_11_3
Package: xeus-dev Version: 3.1.3-1 Severity: serious Dear Debian Science maintainers, I have trouble with linking with libxeus9 since I upgraded nlohmann-json3-dev to 3.11.3-1. It seems to me nlohmann-json3-dev 3.11.3-1. is changing the API of libxeus9 in an incompatible way. /lib/x86_64-linux-gnu/libxeus.so.9 defines xeus::make_null_debugger(xeus::xcontext&, xeus::xconfiguration const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, nlohmann::json_abi_v3_11_2::basic_json, std::allocator >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_2::adl_serializer, std::vector > > const&) while programs compiled with xeus-dev and nlohmann-json3-dev require xeus::make_null_debugger(xeus::xcontext&, xeus::xconfiguration const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, nlohmann::json_abi_v3_11_3::basic_json, std::allocator >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_3::adl_serializer, std::vector >, void> const&)' That is 'nlohmann::json_abi_v3_11_3' instead of 'nlohmann::json_abi_v3_11_2' This causes xeus-based kernels to fail to link. main.cpp:(.text+0x58b): undefined reference to `xeus::make_null_debugger(xeus::xcontext&, xeus::xconfiguration const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, nlohmann::json_abi_v3_11_3::basic_json, std::allocator >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_3::adl_serializer, std::vector >, void> const&)' Downgrading nlohmann-json3-dev to 3.11.2-2 fixes this issue. binNMUing libxeus9 might fix this issue, but will probably silently change the ABI of libxeus9 without updating the shlibs. This is worrysome. I hope I am wrong about that. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
On Sun, Nov 06, 2022 at 02:18:52PM +0100, Jerome BENOIT wrote: > Hello Bill, I got a closer look. > > It appears that [gap-]guava auxiliary binaries do not depend on gap-dev > related packages. > We must discard this dependency a part of resolving the issue. > However, these auxiliary binaries are C compiled executables, that is to say > that they are not scripts. Yes, and as I said the program output is the same on all architectures, so it does not need to match the gap architecture, so there is no reason to handle it specially. In particular there is no use to install two version of the program for two different architectures. > > > > > > > However only the last dir[ectory] may work on > > muti-architecture boxes. > > > > > Here we would need a "/usr/share/gap/pkg/guava/bin/ > > > > > between the two current ones: > > > > > can gap support this ? > > > > > > GAP does not have the notion of the Debian triplet, so it is > > difficult to write a patch > > > > to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/ > > > > I guess that a patch can be written to do so. > > > > This probably requires changing the C code to define a new > > GAPInfo.DEB_HOST_MULTIARCH field. > > Do you have a better idea ? > > I am ready to write such a C patch. Is that okay with you ? Depends on messy it is, I guess ? The problem is that once packages start to use that patch, I cannot just drop the patch if it fails to apply to a new upstream version. Cheers, Bill -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
On Thu, Nov 03, 2022 at 12:25:17PM +0100, Jerome BENOIT wrote: > > > > Indeed, the GAP patch debian/patches/program-path adds > > /usr/share/gap/pkg/guava/bin/ to this list. > > > > > However only the last dir[ectory] may work on muti-architecture boxes. > > > Here we would need a "/usr/share/gap/pkg/guava/bin/ between > > > the two current ones: > > > can gap support this ? > > > > GAP does not have the notion of the Debian triplet, so it is difficult to > > write a patch > > to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/ > > I guess that a patch can be written to do so. This probably requires changing the C code to define a new GAPInfo.DEB_HOST_MULTIARCH field. Do you have a better idea ? > > There is a single /usr/bin for all archs, so in particular a single > > /usr/bin/gap, > > so I do not see why we need to support several /usr/share/gap/pkg/guava/bin, > > especially since mismatched gap-core and gap-guava-bin should work. > > Along this reasonning, > /usr/share/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv8/ has no use. Indeed. gap only need to support it for compatibility with non-debian-packaged gap packages, that uses this kind of directory name. > Please let me fix this guava issue by the week-end. OK, thanks! Bill. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
On Wed, Nov 02, 2022 at 11:13:07AM +0100, Jerome BENOIT wrote:
> Hello Bill, thanks for your message.
Hello Jerome,
Please keep in mind that the BTS does not forward email to the submitter so
you always need to CC them otherwise they will not see your answer!
I only found it by luck, because I see your upload.
> I was trying to fix the issue when you sent the report.
> I isolated the issue as you did.
>
> Solution 1) would the solution on box with one architecture, not on box with
> multi-architectures.
> The package test relies DirectoriesPackagePrograms gap procedure (see
> debian/tests/makecheck.tst )
>
> In Sid environment as provided by autopkgtest(1),
>
> DirectoriesPackagePrograms( "guava" )
>
> gives
>
> [ dir("/usr/share/gap/pkg/guava/bin/"),
> dir("/usr/share/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv8/") ]
>
> which is in agreement with your comments.
Indeed, the GAP patch debian/patches/program-path adds
/usr/share/gap/pkg/guava/bin/ to this list.
> However only the last dir[ectory] may work on muti-architecture boxes.
> Here we would need a "/usr/share/gap/pkg/guava/bin/ between the
> two current ones:
> can gap support this ?
GAP does not have the notion of the Debian triplet, so it is difficult to write
a patch
to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/
There is a single /usr/bin for all archs, so in particular a single
/usr/bin/gap,
so I do not see why we need to support several /usr/share/gap/pkg/guava/bin,
especially since mismatched gap-core and gap-guava-bin should work.
> Meanwhile (before reading your report) I gave a new try by imposing gap >=
> 4.12 .
This is not sufficient, because it will break again when kv9 happens, for no
reason.
Without this bug, gap would be in testing today.
My only way out is to reupload gap with Breaks: gap-guava-bin (<= 3.17+ds-2),
which will waste 5 days.
Also this is an artificial dependency ( guava only requires >= 4.8.0) that will
make
upgrades more complex, again for no reason.
Cheers,
--
Bill.
Imagine a large red swirl here.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1020456: cypari2 FTBFS with PARI 2.15.0
On Fri, Oct 28, 2022 at 07:26:09PM +, Tobias Hansen wrote: > Thanks! I will apply the patch once the pari version with the other fixes is > uploaded. Great! I uploaded it today (pari 2.15.1~pre1-1). I hope it will be OK. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
Package: gap-guava-bin Version: 3.17+ds-2 Severity: normal Dear Debian Science Maintainers, gap-guava-bin includes the directory /usr/lib/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv7 but does not depend on gap-kernel-7. 1) As far as I can see, the guava binaries are not linked against the gap-kernel so are independent of it, so the binaries should just go to /usr/lib/gap/pkg/guava/bin/ 2) the new gap kernel 4.12 is gap-kernel-8 and will not find binaries in x86_64-pc-linux-gnu-default64-kv7 3) if for some reason, you really need x86_64-pc-linux-gnu-default64-kvN, you need to depend on gap-kernel-N. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1023071: please bump gap-kernel-7 to gap-kernel-8
Package: gap-io Version: 4.7.0+ds-2 Severity: important Dear Debian Science team, gap-io depends on gap-kernel-7. This need to be bumped to gap-kernel-8 and rebuild, to work with gap 4.12. Idem for gap-float Thanks in advance, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1020456: cypari2 FTBFS with PARI 2.15.0
On Wed, Oct 05, 2022 at 10:41:58PM +0200, Bill Allombert wrote:
> On Wed, Sep 21, 2022 at 11:57:40PM +0300, Adrian Bunk wrote:
> > Testing cypari2.gen
> > **
> > File
> > "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
> > line ?, in cypari2.gen.Gen.__complex__
> > Failed example:
> > complex(g)
> > Differences (ndiff with -expected +actual):
> > - (2.2847006554165614+0j)
> > + (1.118033988749895+0j)
> > **
> > File
> > "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
> > line ?, in cypari2.gen.__test__.Gen.__complex__ (line 2006)
> > Failed example:
> > complex(g)
> > Differences (ndiff with -expected +actual):
> > - (2.2847006554165614+0j)
> > + (1.118033988749895+0j)
> > **
> > 2 items had failures:
> >1 of 13 in cypari2.gen.Gen.__complex__
> >1 of 13 in cypari2.gen.__test__.Gen.__complex__ (line 2006)
>
> This one is a bug in PARI/GP, that has been fixed in master.
> Once we get to the point it is the only remaining show stopper, I will
> update PARI/GP in sid.
Also I consider the error message change
- PariError: call_python: forbidden multiplication t_VEC (1 elts) * t_VEC
(1 elts)
+ PariError: call_python: incorrect type in qfbcomp (t_VEC)
to be a bug in PARI/GP that I will fix too.
For the others, I join a patch.
Cheers,
--
Bill.
Imagine a large red swirl here.
Index: cypari2-2.1.2/cypari2/handle_error.pyx
===
--- cypari2-2.1.2.orig/cypari2/handle_error.pyx
+++ cypari2-2.1.2/cypari2/handle_error.pyx
@@ -123,7 +123,7 @@ class PariError(RuntimeError):
>>> pari('!@#$%^&*()')
Traceback (most recent call last):
...
-PariError: syntax error, unexpected $undefined
+PariError: syntax error, unexpected invalid token
"""
return self.errtext().rstrip(" .:")
Index: cypari2-2.1.2/cypari2/pari_instance.pyx
===
--- cypari2-2.1.2.orig/cypari2/pari_instance.pyx
+++ cypari2-2.1.2/cypari2/pari_instance.pyx
@@ -1325,9 +1325,9 @@ cdef class Pari(Pari_auto):
>>> pari = cypari2.Pari()
>>> x = pari('x')
>>> pari.genus2red([-5*x**5, x**3 - 2*x**2 - 2*x + 1])
-[1416875, [2, -1; 5, 4; 2267, 1], x^6 - 240*x^4 - 2550*x^3 - 11400*x^2
- 24100*x - 19855, [[2, [2, [Mod(1, 2)]], []], [5, [1, []], ["[V] page 156",
[3]]], [2267, [2, [Mod(432, 2267)]], ["[I{1-0-0}] page 170", []
+[1416875, [2, -1; 5, 4; 2267, 1], [-6*x^5 + 2*x^3 - x, x^3 + 1], [[2,
[2, [Mod(1, 2)]], []], [5, [1, []], ["[V] page 156", [3]]], [2267, [2,
[Mod(432, 2267)]], ["[I{1-0-0}] page 170", []
>>> pari.genus2red([-5*x**5, x**3 - 2*x**2 - 2*x + 1],2267)
-[2267, Mat([2267, 1]), x^6 - 24*x^5 + 10*x^3 - 4*x + 1, [2267, [2,
[Mod(432, 2267)]], ["[I{1-0-0}] page 170", [
+[2267, Mat([2267, 1]), [-6*x^5 + 2*x^3 - x, x^3 + 1], [2267, [2,
[Mod(432, 2267)]], ["[I{1-0-0}] page 170", [
"""
cdef Gen t0 = objtogen(P)
if p is None:
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1020436: giac FTBFS with PARI 2.15.0
On Wed, Oct 19, 2022 at 09:27:23AM +, Tobias Hansen wrote: > I tried rebuilding with this patch from sagemath: Thanks! > |diff --git a/src/pari.cc b/src/pari.cc index 76ce8e1..50d08ab 100644 --- > a/src/pari.cc +++ b/src/pari.cc @@ -40,6 +40,13 @@ using namespace std; > #ifdef HAVE_LIBPARI +// Anyarg disappeared from PARI 2.15.0 +#ifdef > __cplusplus +# define ANYARG ... +#else +# define ANYARG +#endif + #ifdef > HAVE_PTHREAD_H #include #endif| > > > *** the thread stack overflows ! > current stack size: 1024000 (0.977 Mbytes) > [hint] set 'threadsizemax' to a nonzero value in your GPRC > *** matdet: Warning: increasing stack size to 2048000. > *** at top-level: matdet([-10,-7,6,-7,1,4,-1,-2,-2,-5,1,7,-6,7,- > *** ^-- > *** matdet: the thread stack overflows ! > current stack size: 1024000 (0.977 Mbytes) > [hint] set 'threadsizemax' to a nonzero value in your GPRC Probably you just need to increase threadsize or parisize, 1024000 is very small. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1020456: cypari2 FTBFS with PARI 2.15.0
On Wed, Sep 21, 2022 at 11:57:40PM +0300, Adrian Bunk wrote: > Testing cypari2.gen > ** > File > "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so", > line ?, in cypari2.gen.Gen.__complex__ > Failed example: > complex(g) > Differences (ndiff with -expected +actual): > - (2.2847006554165614+0j) > + (1.118033988749895+0j) > ** > File > "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so", > line ?, in cypari2.gen.__test__.Gen.__complex__ (line 2006) > Failed example: > complex(g) > Differences (ndiff with -expected +actual): > - (2.2847006554165614+0j) > + (1.118033988749895+0j) > ** > 2 items had failures: >1 of 13 in cypari2.gen.Gen.__complex__ >1 of 13 in cypari2.gen.__test__.Gen.__complex__ (line 2006) This one is a bug in PARI/GP, that has been fixed in master. Once we get to the point it is the only remaining show stopper, I will update PARI/GP in sid. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1020456: cypari2 FTBFS with PARI 2.15.0
On Wed, Sep 21, 2022 at 11:57:40PM +0300, Adrian Bunk wrote:
> Source: cypari2
> Version: 2.1.2-2
> Severity: serious
> Tags: ftbfs bookworm sid
>
> https://buildd.debian.org/status/logs.php?pkg=cypari2=2.1.2-2%2Bb3
>
> Differences (ndiff with -expected +actual):
> Traceback (most recent call last):
> - ...
> - PariError: call_python: forbidden multiplication t_VEC (1 elts) * t_VEC
> (1 elts)
> + File "/usr/lib/python3.10/doctest.py", line 1350, in __run
> + exec(compile(example.source, filename, "single",
> + File " 145)[18]>", line 1, in
> + mul([1], [2])
> + File "cypari2/gen.pyx", line 4107, in cypari2.gen.Gen.__call__
> + sig_on()
> + File "cypari2/handle_error.pyx", line 213, in
> cypari2.handle_error._pari_err_handle
> + raise PariError(errnum, pari_error_string, clone_gen_noclear(E))
> + PariError: call_python: incorrect type in qfbcomp (t_VEC)
a
Some explanation for the failure.
PARI has merged t_QFI and t_QFR to a new type t_QFB. This explains this error.
This might requires some actual fix in cpari2.
> **
> File
> "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/closure.cpython-310-x86_64-linux-gnu.so",
> line ?, in cypari2.closure.objtoclosure
> Failed example:
> mul([1], [2])
> Differences (ndiff with -expected +actual):
> Traceback (most recent call last):
> - ...
> - PariError: call_python: forbidden multiplication t_VEC (1 elts) * t_VEC
> (1 elts)
> + File "/usr/lib/python3.10/doctest.py", line 1350, in __run
> + exec(compile(example.source, filename, "single",
> + File "", line 1, in
> + mul([1], [2])
> + File "cypari2/gen.pyx", line 4107, in cypari2.gen.Gen.__call__
> + sig_on()
> + File "cypari2/handle_error.pyx", line 213, in
> cypari2.handle_error._pari_err_handle
> + raise PariError(errnum, pari_error_string, clone_gen_noclear(E))
> + PariError: call_python: incorrect type in qfbcomp (t_VEC)
Idem
> **
> 2 items had failures:
>1 of 19 in cypari2.closure.__test__.objtoclosure (line 145)
>1 of 19 in cypari2.closure.objtoclosure
> ***Test Failed*** 2 failures.
>
> Testing cypari2.convert
>
> Testing cypari2.gen
> **
> File
> "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
> line ?, in cypari2.gen.Gen.__complex__
> Failed example:
> complex(g)
> Differences (ndiff with -expected +actual):
> - (2.2847006554165614+0j)
> + (1.118033988749895+0j)
> **
> File
> "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
> line ?, in cypari2.gen.__test__.Gen.__complex__ (line 2006)
> Failed example:
> complex(g)
> Differences (ndiff with -expected +actual):
> - (2.2847006554165614+0j)
> + (1.118033988749895+0j)
> **
> 2 items had failures:
>1 of 13 in cypari2.gen.Gen.__complex__
>1 of 13 in cypari2.gen.__test__.Gen.__complex__ (line 2006)
> ***Test Failed*** 2 failures.
>
> Testing cypari2.handle_error
> **
> File
> "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/handle_error.cpython-310-x86_64-linux-gnu.so",
> line ?, in cypari2.handle_error.__test__.PariError.__str__ (line 104)
> Failed example:
> pari('!@#$%^&*()')
> Differences (ndiff with -expected +actual):
> Traceback (most recent call last):
> - ...
> + File "/usr/lib/python3.10/doctest.py", line 1350, in __run
> + exec(compile(example.source, filename, "single",
> + File " 104)[3]>", line 1, in
> + pari('!@#$%^&*()')
> + File "cypari2/pari_instance.pyx", line 832, in
> cypari2.pari_instance.Pari.__call__
> + cdef Gen g = objtogen(s)
> + File "cypari2/gen.pyx", line 4810, in cypari2.gen.objtogen
> + cdef GEN g = PyObject_AsGEN(s)
> + File "cypari2/convert.pyx", line 557, in
> cypari2.convert.PyObject_AsGEN
> + sig_on()
> + File "cypari2/handle_error.pyx", line 213, in
> cypari2.handle_error._pari_err_handle
> + raise PariError(errnum, pari_error_string, clone_gen_noclear(E))
> - PariError: syntax error, unexpected $undefined
> ? -- ^
> + PariError: syntax error, unexpected invalid token
> ? + ^
This is actually a
Bug#1020436: giac FTBFS with PARI 2.15.0
On Wed, Sep 21, 2022 at 09:01:51PM +0300, Adrian Bunk wrote: > Source: giac > Version: 1.9.0.19+dfsg2-1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/logs.php?pkg=giac=1.9.0.19%2Bdfsg2-1%2Bb1 > > ... > pari.cc: At global scope: > pari.cc:752:17: error: typedef ‘giac::PFGEN’ is initialized (use ‘decltype’ > instead) > 752 | typedef GEN (*PFGEN)(ANYARG); > | ^ > pari.cc:752:24: error: ‘ANYARG’ was not declared in this scope This is my comment on this bug: PARI used to define ANYARG as #ifdef __cplusplus # define ANYARG ... #else # define ANYARG #endif This definition was removed because newer gcc/clang do not like to call function without prototype and it was not particularly useful. So you can replace this by typedef GEN (*PFGEN)(); if you like, but recent gcc 12 will issue warning. In PARI we changed EVAL_f to cast the pointer to the right prototype before calling it. Sorry for the trouble. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1007208: libdart-external-convhull-3d-dev has circular Depends on libdart-dev
Package: libdart-external-convhull-3d-dev Version: 6.12.1+dfsg4-11 Severity: important Hello Debian Science Maintainers, There is a circular dependency between libdart-external-convhull-3d-dev and libdart-dev: libdart-external-convhull-3d-dev:Depends: libdart-dev libdart-dev :Depends: libdart-external-convhull-3d-dev Circular dependencies involving shared libraries are known to cause problems during upgrade between stable releases, so we should try to avoid them. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#979809: libopencv-contrib4.5 has circular Depends on libopencv-superres4.5
Package: libopencv-contrib4.5 Version: 4.5.1+dfsg-4 Severity: important Hello Debian Science Team, There is a circular dependency between libopencv-contrib4.5 and libopencv-superres4.5: libopencv-contrib4.5:Depends: libopencv-superres4.5 (= 4.5.1+dfsg-4) libopencv-superres4.5 :Depends: libopencv-contrib4.5 (>= 4.5.1+dfsg) Circular dependencies involving shared libraries are known to cause problems during upgrade between stable releases, so we should try to avoid them. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#855081: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#855081: fixed in giac 1.6.0.25+dfsg1-3)
On Tue, Nov 03, 2020 at 08:54:07AM +, Debian Bug Tracking System wrote: >* Mark the actually supported architectures. (Closes: #855080, #855081) Sorry Julien, but this is not an appropriate way to deal with this. What you should do is ask of debian-hurd for someone to provide a patch. Cheers, Bill. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#973351: cypari2 need an update for pari-2.13
Source: cypari2 Version: 2.1.1-2 Severity: important Tags: patch Dear Debian Science Team, cypari2 need an update to be compatible with pari 2.13.0 (in experimental) which will be uploded to sid soon. The fix needed is simple however the doctests are very fragile (they depend on unspecified behaviors) and need to be updated (for example they depend on the documentation of some functions). The patch does not attempt to deal with the doctests failure. Cheers, -- Bill. Imagine a large red swirl here. Index: cypari2-2.1.1/cypari2/gen.pyx === --- cypari2-2.1.1.orig/cypari2/gen.pyx +++ cypari2-2.1.1/cypari2/gen.pyx @@ -4109,7 +4109,7 @@ cdef class Gen(Gen_base): non-constant polynomial, or False if f is reducible or constant. """ sig_on() -t = isirreducible(self.g) +t = polisirreducible(self.g) clear_stack() return t != 0 Index: cypari2-2.1.1/cypari2/paridecl.pxd === --- cypari2-2.1.1.orig/cypari2/paridecl.pxd +++ cypari2-2.1.1/cypari2/paridecl.pxd @@ -3850,7 +3850,7 @@ cdef extern from *: # PARI headers a GEN glcm0(GEN x, GEN y) GEN gp_factor0(GEN x, GEN flag) GEN idealfactorback(GEN nf, GEN L, GEN e, int red) -longisirreducible(GEN x) +longpolisirreducible(GEN x) GEN newtonpoly(GEN x, GEN p) GEN nffactorback(GEN nf, GEN L, GEN e) GEN nfrootsQ(GEN x) -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#966607: libopenblas0 has circular Depends on libopenblas0-openmp|libopenblas0-openmp|libopenblas0-serial
Package: libopenblas0 Version: 0.3.10+ds-2 Severity: important Dear Debian Science Team, There is a circular dependency between libopenblas0 and libopenblas0-pthread|libopenblas0-openmp|libopenblas0-serial libopenblas0:Depends: libopenblas0-pthread | libopenblas0-openmp | libopenblas0-serial libopenblas0-openmp :Depends: libopenblas0 Circular dependencies involving shared libraries are known to cause problems during upgrade between stable releases, so we should try to avoid them. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#965011: fplll: manpage refer to nonexistent README.html
Package: fplll-tools Version: 5.2.1-2 Severity: normal Dear Debian science team, man fplll says: See /usr/share/doc/libfplll-dev/README.html from the libfplll-dev package for more details. However the file /usr/share/doc/libfplll-dev/README.html does not exist. In particular the manpage should document what input matrices format are supported. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#963890: libopencv-contrib4.2: circular dependency with libopencv-superres4.2
Package: libopencv-contrib4.2 Version: 4.2.0+dfsg-6+b1 Severity: important Hello Debian Science Team, There is a circular dependency between libopencv-contrib4.2 and libopencv-superres4.2: libopencv-contrib4.2:Depends: libopencv-superres4.2 (= 4.2.0+dfsg-6+b1) libopencv-superres4.2 :Depends: libopencv-contrib4.2 (>= 4.2.0+dfsg) Circular dependencies are known to cause problems during upgrade, so we should try to avoid them. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#963870: libdolfinx-dev: circular dependency with libdolfinx-complex-dev, libdolfinx-real-dev
Package: libdolfinx-dev Version: 2019.2.0~git20200420.6043d6d-6 Severity: important Hello Debian Science Team, There is a circular dependency between libdolfinx-dev, libdolfinx-complex-dev and libdolfinx-real-dev: libdolfinx-dev :Depends: libdolfinx-real-dev, libdolfinx-complex-dev libdolfinx-complex-dev :Depends: libdolfinx-dev libdolfinx-real-dev :Depends: libdolfinx-dev Circular dependencies are known to cause problems during upgrade, so we should try to avoid them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#963850: python3-slepc4py: circular dependency hell
Package: python3-slepc4py Version: 3.13.0-2 Severity: important Hello Debian Science Maintainers, There is a circular dependency between python3-slepc4py, python3-slepc4py-complex, python3-slepc4py-complex3.13, python3-slepc4py-real and python3-slepc4py-real3.13: python3-slepc4py:Depends: python3-slepc4py-real, python3-slepc4py-complex, python3-slepc4py-real3.13, python3-slepc4py-complex3.13 python3-slepc4py-complex:Depends: python3-slepc4py-complex3.13 python3-slepc4py-complex3.13:Depends: python3-slepc4py (>= 3.12.0-5~) python3-slepc4py-real :Depends: python3-slepc4py-real3.13 python3-slepc4py-real3.13 :Depends: python3-slepc4py (>= 3.12.0-5~) Complex circular dependencies are known to cause problems during upgrade, so we should try to avoid them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#963847: python3-petsc4py: circular dependency hell
Package: python3-petsc4py Version: 3.12.0-8 Severity: important Hello Debian Science Maintainers, There is a circular dependency between python3-petsc4py, python3-petsc4py-64-complex, python3-petsc4py-64-complex3.13, python3-petsc4py-64-real, python3-petsc4py-64-real3.13, python3-petsc4py-complex, python3-petsc4py-complex3.12, python3-petsc4py-complex3.13, python3-petsc4py-real, python3-petsc4py-real3.12 and python3-petsc4py-real3.13: python3-petsc4py:Depends: python3-petsc4py-real, python3-petsc4py-complex, python3-petsc4py-real3.12, python3-petsc4py-complex3.12 python3-petsc4py-64-complex :Depends: python3-petsc4py-64-complex3.13 python3-petsc4py-64-complex3.13 :Depends: python3-petsc4py (>= 3.12.0-5~) python3-petsc4py-64-real:Depends: python3-petsc4py-64-real3.13 python3-petsc4py-64-real3.13:Depends: python3-petsc4py (>= 3.12.0-5~) python3-petsc4py-complex:Depends: python3-petsc4py-complex3.12 python3-petsc4py-complex3.12:Depends: python3-petsc4py (>= 3.12.0-5~) python3-petsc4py-complex3.13:Depends: python3-petsc4py (>= 3.12.0-5~) python3-petsc4py-real :Depends: python3-petsc4py-real3.12 python3-petsc4py-real3.12 :Depends: python3-petsc4py (>= 3.12.0-5~) python3-petsc4py-real3.13 :Depends: python3-petsc4py (>= 3.12.0-5~) Complex circular dependencies are known to cause problems during upgrade, so we should try to avoid them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#959378: gap-guava-bin: please update for new GAP ABI
Package: gap-guava-bin Version: 3.15+ds-1 Severity: serious Dear Debian Science Maintainers, Please update gap-guava for the new GAP ABI. 1) GAP 4.11.0 includes libgap7, libgap-dev as a normal Debian shared library package. 2) There is now an officially supported ABI for the GAP kernel. the current kernel ABI version is 7 In the file /usr/lib/gap/sysinfo.gap GAParch=x86_64-pc-linux-gnu-default64-kv7 GAP_KERNEL_MAJOR_VERSION=7 kv7 mean kernel version 7. If your package is built against the GAP 4.11.0 kernel, please make it depends on gap-kernel-7. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#958495: Fwd: gap-io: please update for new GAP ABI
On Thu, Apr 30, 2020 at 10:35:49AM +0400, Jerome BENOIT wrote:
> Dear Bill, thanks for your message.
Hello Jerome
> I understand that GAP comes now with an official ABI.
Yes, one for gap-core which is gap-kernel-7,
and one for libgap which is libgap7, but they should be
compatible.
> Currently the package gap-io depends for building on gap and gap-dev,
> while the package itself depends only on gap.
Yes. Ideally at some point it will be build against libgap, but not yet.
> You asked to make it depends on gap-kernel-7.
> My understanding is that gap-kernel-7 is not a package.
gap-kernel-7 is a virtual package provided by gap-core.
> I could build the package gap-io on a sane Sid environment (schroot)
> without modification. But, the resulting gap-io package still depends
> only depends on gap.
> Do you mean that I must add by hand libgap7 to the list of dependencies
> (as ${shlibs:Depends} does not add it) ?
No, I suggested you add gap-kernel-7 by hand instead.
There might be a way to automate this by reading
/usr/lib/gap/sysinfo.gap, recovering GAP_KERNEL_MAJOR_VERSION
and adding a dpkg substvar for gap-kernel-$GAP_KERNEL_MAJOR_VERSION
Cheers,
--
Bill.
Imagine a large red swirl here.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#958802: gap-float: please update for new GAP ABI
Package: gap-float Version: 0.9.1+ds-5 Severity: serious Dear Debian Science Maintainers, Please update gap-float for the new GAP ABI. 1) GAP 4.11.0 includes libgap7, libgap-dev as a normal Debian shared library package. 2) There is now an officially supported ABI for the GAP kernel. the current kernel ABI version is 7 In the file /usr/lib/gap/sysinfo.gap GAParch=x86_64-pc-linux-gnu-default64-kv7 GAP_KERNEL_MAJOR_VERSION=7 kv7 mean kernel version 7. If your package is built against the GAP 4.11.0 kernel, please make it depends on gap-kernel-7. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#958495: gap-io: please update for new GAP ABI
Package: gap-io Version: 4.7.0+ds-1 Severity: serious Dear Debian Science Maintainers, Please update gap-io for the new GAP ABI. 1) GAP 4.11.0 includes libgap7, libgap-dev as a normal Debian shared library package. 2) There is now an officially supported ABI for the GAP kernel. the current kernel ABI version is 7 In the file /usr/lib/gap/sysinfo.gap GAParch=x86_64-pc-linux-gnu-default64-kv7 GAP_KERNEL_MAJOR_VERSION=7 kv7 mean kernel version 7. If your package is built against the GAP 4.11.0 kernel, please make it depends on gap-kernel-7. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#932356: autotest fail with gap 4.10.2
Source: gap-guava Version: 3.14+ds-1 Severity: serious Dear Debian Science Maintainers, gap-guava 3.14+ds-1 is failing the autotest with gap 4.10.2. Please rebuild the package for the new GAP version. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Bug#912914: gap breaks multiple autopkgtests
On Mon, Dec 31, 2018 at 10:08:10AM +0400, Jerome BENOIT wrote: > Hello, > > It rocks well. Thanks the fix. > Meanwhile I have noticed some FTBR on GAP packages whose documentation is > composed via a old fashion way. > I will have a closer look later. Maybe you need to set LC_ALL=C ? I will do a final upload of GAP to fix the FTBR today or tomorrow. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Bug#912914: gap breaks multiple autopkgtests
On Tue, Dec 25, 2018 at 07:10:15PM +0400, Jerome BENOIT wrote: > On 25/12/2018 18:00, Bill Allombert wrote: > > On Tue, Dec 25, 2018 at 04:45:32PM +0400, Jerome BENOIT wrote: > >> Hello, > >> > >> I have just have began to have a look on this issue. > >> > >> It appears that gap-io does no more build with gap 4.10 : > >> a closer look reveals that /usr/lib/gap is missing some folder previously > >> provided with the gap-dev package: > >> > >> /usr/lib/gap/bin/x86_64-pc-linux-gnu-default64 > >> /usr/lib/gap/gen > >> /usr/lib/gap/src > >> > >> I have also noticed that > >> > >> gac is no more on /us/bin but in /usr/lib/gap > > > > This is expected: > > > > 1) gac is still in /usr/bin/gac but now /usr/lib/gap/gac is a symlink to > > /usr/bin/gac which is provided for compatibility with GAP. > > > > 2) Upstream has removed /usr/lib/gap/bin/x86_64-pc-linux-gnu-default64, > > /usr/lib/gap/gen and /usr/lib/gap/src are now under > > /usr/lib/x86_64-linux-gnu/gap/obj > > > > I hope it is OK. > > This is a source of trouble for now: > 1] /m4/ac_find_gap.m4 does not work any more I have uploaded gap_4r10p0-4 which should fix this issue. Thanks for telling me about it. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Bug#912914: gap breaks multiple autopkgtests
On Tue, Dec 25, 2018 at 07:10:15PM +0400, Jerome BENOIT wrote: > > > On 25/12/2018 18:00, Bill Allombert wrote: > > On Tue, Dec 25, 2018 at 04:45:32PM +0400, Jerome BENOIT wrote: > >> Hello, > >> > >> I have just have began to have a look on this issue. > >> > >> It appears that gap-io does no more build with gap 4.10 : > >> a closer look reveals that /usr/lib/gap is missing some folder previously > >> provided with the gap-dev package: > >> > >> /usr/lib/gap/bin/x86_64-pc-linux-gnu-default64 > >> /usr/lib/gap/gen > >> /usr/lib/gap/src > >> > >> I have also noticed that > >> > >> gac is no more on /us/bin but in /usr/lib/gap > > > > This is expected: > > > > 1) gac is still in /usr/bin/gac but now /usr/lib/gap/gac is a symlink to > > /usr/bin/gac which is provided for compatibility with GAP. > > > > 2) Upstream has removed /usr/lib/gap/bin/x86_64-pc-linux-gnu-default64, > > /usr/lib/gap/gen and /usr/lib/gap/src are now under > > /usr/lib/x86_64-linux-gnu/gap/obj > > > > I hope it is OK. > > This is a source of trouble for now: > 1] /m4/ac_find_gap.m4 does not work any more I will try to fix gap-dev to avoid this. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: Bug#912914: gap breaks multiple autopkgtests
On Tue, Dec 25, 2018 at 04:45:32PM +0400, Jerome BENOIT wrote: > Hello, > > I have just have began to have a look on this issue. > > It appears that gap-io does no more build with gap 4.10 : > a closer look reveals that /usr/lib/gap is missing some folder previously > provided with the gap-dev package: > > /usr/lib/gap/bin/x86_64-pc-linux-gnu-default64 > /usr/lib/gap/gen > /usr/lib/gap/src > > I have also noticed that > > gac is no more on /us/bin but in /usr/lib/gap This is expected: 1) gac is still in /usr/bin/gac but now /usr/lib/gap/gac is a symlink to /usr/bin/gac which is provided for compatibility with GAP. 2) Upstream has removed /usr/lib/gap/bin/x86_64-pc-linux-gnu-default64, /usr/lib/gap/gen and /usr/lib/gap/src are now under /usr/lib/x86_64-linux-gnu/gap/obj I hope it is OK. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#916479: libtf2-dev has circular Depends on libtf2-geometry-msgs-dev
Package: libtf2-dev Version: 0.6.5-3 Severity: important Hello Debian Science Maintainers, There is a circular dependency between libtf2-dev and libtf2-geometry-msgs-dev: libtf2-dev :Depends: libtf2-geometry-msgs-dev libtf2-geometry-msgs-dev:Depends: libtf2-dev Circular dependencies are known to cause problems during upgrade between stable releases, so we should try to avoid them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#913725: New upstream version 2.9.1
Hello Jérome, Could you fix gap-sonata in unstable so that gap 4.9.3 can enter testing ? Cheers, Bill -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#913725: New upstream version 2.9.1
Package: gap-sonata Version: 2.8+ds-1 Severity: normal Dear Debian Science Maintainers, a new upstream version of sonata, 2.9.1, has been released. Please consider updating the package. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#905302: New upstream version 1.2.1
On Thu, Aug 02, 2018 at 08:27:38PM +0200, Bill Allombert wrote: > Package: cypari2 > Version: 1.1.4-3 > Severity: wishlist > > Hello Debian Science Team, > > there is a new upstream version of cypari2 (1.2.1) available. Hello Debian Science Team, It seems cypari2 1.1.4 FTBFS with pari 2.11.0 However according to <https://travis-ci.org/defeo/cypari2>, cypari2 1.2.1 should work. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#905302: New upstream version 1.2.1
Package: cypari2 Version: 1.1.4-3 Severity: wishlist Hello Debian Science Team, there is a new upstream version of cypari2 (1.2.1) available. Cheers, -- Bill. Imagine a large red swirl here. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
