Processed: bug 936557 is forwarded to https://github.com/freeorion/freeorion/pull/2653
Processing commands for cont...@bugs.debian.org: > forwarded 936557 https://github.com/freeorion/freeorion/pull/2653 Bug #936557 [src:freeorion] freeorion: Python2 removal in sid/bullseye Changed Bug forwarded-to-address to 'https://github.com/freeorion/freeorion/pull/2653' from 'https://freeorion.org/forum/viewtopic.php?f=9&t=11181'. > thanks Stopping processing here. Please contact me if you need assistance. -- 936557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936557 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Matthew, On Thu, Apr 30, 2020 at 05:53:29PM -0700, Matthew Fernandez wrote: > > Is the priority goal here to simply ship a non-crashing clustalo mipsel > binary that BioPython can depend on? If so, maybe we can just disable > compiler optimisation (-O0) and this may avoid provoking the bus error. Of > course this doesn’t fix the underlying problem(s), but it looks as if > debugging this to its root cause is going to result in the Debian package > carrying a lot of invasive dquilt patches on top of upstream. OTOH I don’t > know the performance requirements of BioPython and maybe an unoptimised > clustalo is unacceptable to it. I need to admit the priority goal is to be really sure that the clustalo code has no hidden issues which might crash on architectures that are used in practical applications. I would have no problems to simply exclude clustalo for mipsel architecture completely - if I could be sure that it works properly. So the major reason for this debugging session is to make sure that clustalo runs properly *on all other* architectures while loosing mipsel would be no real loss for practival usage of clustalo and its rdepends. To follow your hints I cared for -O0 optimisation flags (which is possible via configure options which uncovers some syntax errors in comments :-( which I fixed as well) and tried to rebuild on the mipsel host provided by Debian. Unfortunately the bus error remains. Due to the advise here that valgrind works properly only for -O0 I'm reposting the valgrind output here: (sid_mipsel-dchroot)tille@eller:~/clustalo$ valgrind -s src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force ==13209== Memcheck, a memory error detector ==13209== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==13209== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==13209== Command: src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force ==13209== ==13209== Conditional jump or move depends on uninitialised value(s) ==13209==at 0x4007828: cached_fpabi_reject_phdr_p (dl-machine-reject-phdr.h:57) ==13209==by 0x4007828: elf_machine_reject_phdr_p (dl-machine-reject-phdr.h:217) ==13209==by 0x4008080: open_verify.constprop.0 (dl-load.c:1688) ==13209==by 0x4009D7C: _dl_map_object (dl-load.c:2181) ==13209==by 0x40011F8: map_doit (rtld.c:607) ==13209==by 0x401B2A8: _dl_catch_exception (dl-error-skeleton.c:196) ==13209==by 0x401B334: _dl_catch_error (dl-error-skeleton.c:215) ==13209==by 0x4001138: do_preload (rtld.c:778) ==13209==by 0x4002560: handle_preload_list (rtld.c:879) ==13209==by 0x4005B08: dl_main (rtld.c:1684) ==13209==by 0x401A094: _dl_sysdep_start (dl-sysdep.c:253) ==13209==by 0x400199C: _dl_start_final (rtld.c:447) ==13209==by 0x4001D44: _dl_start (rtld.c:539) ==13209== ==13209== Invalid read of size 1 ==13209==at 0x486F558: ??? (in /usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8) ==13209==by 0x486F5F0: ??? (in /usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8) ==13209== Address 0x4d655c5 is 0 bytes after a block of size 37 alloc'd ==13209==at 0x484B89C: malloc (in /usr/lib/mipsel-linux-gnu/valgrind/vgpreload_memcheck-mips32-linux.so) ==13209==by 0x134D1C: CkMalloc (util.c:83) ==13209== ==13209== Invalid read of size 4 ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346) ==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835) ==13209==by 0x11A6C4: Align (clustal-omega.c:1221) ==13209==by 0x1171C8: MyMain (mymain.c:1192) ==13209==by 0x113CCC: main (main.cpp:469) ==13209== Address 0x8060 is not stack'd, malloc'd or (recently) free'd ==13209== ==13209== ==13209== Process terminating with default action of signal 10 (SIGBUS) ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346) ==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835) ==13209==by 0x11A6C4: Align (clustal-omega.c:1221) ==13209==by 0x1171C8: MyMain (mymain.c:1192) ==13209==by 0x113CCC: main (main.cpp:469) ==13209== ==13209== HEAP SUMMARY: ==13209== in use at exit: 8,039 bytes in 34 blocks ==13209== total heap usage: 112 allocs, 78 frees, 77,811 bytes allocated ==13209== ==13209== LEAK SUMMARY: ==13209==definitely lost: 128 bytes in 2 blocks ==13209==indirectly lost: 0 bytes in 0 blocks ==13209== possibly lost: 0 bytes in 0 blocks ==13209==still reachable: 7,911 bytes in 32 blocks ==13209== suppressed: 0 bytes in 0 blocks ==13209== Rerun with --leak-check=full to see details of leaked memory ==13209== ==13209== Use --track-origins=yes to see where uninitialised values come from ==13209== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) ==13209== ==13209== 1 errors in context 1 of 3: ==13209== Invalid read of size 4 ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346) ==13
Processed: your mail
Processing commands for cont...@bugs.debian.org: > reassign 959201 libyaml-cpp0.6 0.6.3-1 Bug #959201 [jami-daemon] jami-daemon: dring does not start due to a symbol lookup error Bug reassigned from package 'jami-daemon' to 'libyaml-cpp0.6'. No longer marked as found in versions ring/20190215.1.f152c98~ds1-1. Ignoring request to alter fixed versions of bug #959201 to the same values previously set Bug #959201 [libyaml-cpp0.6] jami-daemon: dring does not start due to a symbol lookup error Marked as found in versions yaml-cpp/0.6.3-1. > End of message, stopping processing here. Please contact me if you need assistance. -- 959201: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959201 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#959201: Acknowledgement (jami-daemon: dring does not start due to a symbol lookup error)
Hi, the cause seems to be an ABI change in /usr/lib/x86_64-linux- gnu/libyaml-cpp.so.0.6.3 in package libyaml-cpp0.6 between versions 0.6.2-4 and 0.6.3-1: While 0.6.2-4 exported 0006bd60 B _ZN4YAML6detail9node_data12empty_scalarB5cxx11E 0.6.3-1 now exports 00029af0 T _ZN4YAML6detail9node_data12empty_scalarB5cxx11Ev I looked at the symbols which dring needs: 20190215.1.f152c98~ds1-1+b1 looks for the one exported by 0.6.2-4 of libyaml-cpp0.6 004ee180 B _ZN4YAML6detail9node_data12empty_scalarB5cxx11E After recompilation against libyaml-cpp0.6 0.6.3-1 it looks like this: U _ZN4YAML6detail9node_data12empty_scalarB5cxx11Ev If I understand this correctly, the upload of libyaml-cpp0.6 lacks a bump of the SO name to reflect the ABI change and this bug has to be forwarded to libyaml-cpp0.6. Cheers, Bruno signature.asc Description: This is a digitally signed message part
Bug#936723: marked as done (ifeffit: Python2 removal in sid/bullseye)
Your message dated Fri, 01 May 2020 14:30:24 +1000 with message-id <58836028.v9rg4Cycpm@simurgh> and subject line Re: Bug#936723: ifeffit: Python2 removal in sid/bullseye has caused the Debian Bug report #936723, regarding ifeffit: Python2 removal in sid/bullseye 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.) -- 936723: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936723 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:ifeffit Version: 2:1.2.11d-10.2 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests. Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If the conversion or removal needs action on another package first, please document the blocking by using the BTS affects command, like affects + src:ifeffit If there is no py2removal bug for that reverse-dependency, please file a bug on this package (similar to this bug report). If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list. --- End Message --- --- Begin Message --- Version: 2:1.2.11d-10.2+rm ifeffit has been removed from Debian, so closing. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7--- End Message ---
Bug#959157: fix for CVE-2020-1749 in linux-image-4.19.0-9 breaks wireguard
https://git.zx2c4.com/wireguard-linux-compat/commit/?id=4602590adee92557847e61c8cd14445d35fbfa2e
Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
> One small issue... Valgrind recommends -O0 or -O1 TIL :) Thanks, Jeff! > You can sometimes locate a bus error at build time with -Wcast-align. > At runtime you can usually locate them with -fsanitize=undefined. I had previously tried UBSan and, while it turned up a number of shifting and strict aliasing violations, it did not find anything that I believe could be the cause of the mipsel bus error. > I can't track the trail any further. The source code is missing for > pvm_pkdouble and pvm_upkdouble. I would be very suspect of > pvm_pkdouble and pvm_upkdouble. Unfortunately I think the reason you can’t find their source is that this code is unused. It is inside a ifdef SRE_ENABLE_PVM block and this macro is not defined during the build. You can confirm this by deleting these lines and recompiling. AFAICT the code in src/squid is a library taken wholesale from somewhere else and then modified (see src/squid/clustalo.README). It contains a lot of code that goes unused in Clustal Omega. Is the priority goal here to simply ship a non-crashing clustalo mipsel binary that BioPython can depend on? If so, maybe we can just disable compiler optimisation (-O0) and this may avoid provoking the bus error. Of course this doesn’t fix the underlying problem(s), but it looks as if debugging this to its root cause is going to result in the Debian package carrying a lot of invasive dquilt patches on top of upstream. OTOH I don’t know the performance requirements of BioPython and maybe an unoptimised clustalo is unacceptable to it.
Processed: reassign 959157 to wireguard-dkms
Processing commands for cont...@bugs.debian.org: > reassign 959157 wireguard-dkms Bug #959157 [wireguard] fix for CVE-2020-1749 in linux-image-4.19.0-9 breaks wireguard Bug reassigned from package 'wireguard' to 'wireguard-dkms'. No longer marked as found in versions wireguard/1.0.20200319-1~bpo10+1. Ignoring request to alter fixed versions of bug #959157 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 959157: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959157 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#937431: pyepl: Python2 removal in sid/bullseye
> > yes, AFAIK it is dead. Let's RM. you ? me ? ;) > Please go ahead :-) FTR #959213 -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik signature.asc Description: PGP signature
Bug#955064: marked as done (grpc: FTBFS with Sphinx 2.4: distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('Sphinx~=1.8.1'))
Your message dated Thu, 30 Apr 2020 22:05:15 +
with message-id
and subject line Bug#955064: fixed in grpc 1.26.0-3
has caused the Debian Bug report #955064,
regarding grpc: FTBFS with Sphinx 2.4: distutils.errors.DistutilsError: Could
not find suitable distribution for Requirement.parse('Sphinx~=1.8.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.)
--
955064: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955064
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: grpc
Version: 1.26.0-2
Severity: important
Tags: ftbfs
User: python-modules-t...@lists.alioth.debian.org
Usertags: sphinx2.4
Hi,
grpc fails to build with Sphinx 2.4, currently available in
experimental.
Relevant part (hopefully):
> make[2]: Entering directory '/<>'
> rm -f -rf /<>/objs /<>/libs /<>/bins
> /<>/gens cache.mk
> make[2]: Leaving directory '/<>'
> dh_auto_clean -O--buildsystem=pybuild
> I: pybuild base:217: python3.7 setup.py clean
> Compiling src/python/grpcio/grpc/_cython/cygrpc.pyx because it changed.
> [1/1] Cythonizing src/python/grpcio/grpc/_cython/cygrpc.pyx
> /usr/lib/python3/dist-packages/Cython/Compiler/Main.py:369: FutureWarning:
> Cython directive 'language_level' not set, using 2 for now (Py2). This will
> change in a later release! File:
> /<>/src/python/grpcio/grpc/_cython/cygrpc.pxd
> tree = Parsing.p_module(s, pxd, full_module_name)
> WARNING: The pip package is not available, falling back to EasyInstall for
> handling setup_requires/test_requires; this is deprecated and will be removed
> in a future version.
>
> Note: Bypassing https://pypi.org/simple/Sphinx/ (disallowed host; see
> http://bit.ly/2hrImnY for details).
>
>
> Note: Bypassing https://pypi.org/simple/ (disallowed host; see
> http://bit.ly/2hrImnY for details).
>
> No local packages or working download links found for Sphinx~=1.8.1
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 62, in
> fetch_build_egg
> pkg_resources.get_distribution('pip')
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 481,
> in get_distribution
> dist = get_provider(dist)
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 357,
> in get_provider
> return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900,
> in require
> needed = self.resolve(parse_requirements(requirements))
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786,
> in resolve
> raise DistributionNotFound(req, requirers)
> pkg_resources.DistributionNotFound: The 'pip' distribution was not found and
> is required by the application
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "setup.py", line 400, in
> cmdclass=COMMAND_CLASS,
> File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 144, in
> setup
> _install_setup_requires(attrs)
> File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 139, in
> _install_setup_requires
> dist.fetch_build_eggs(dist.setup_requires)
> File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 721, in
> fetch_build_eggs
> replace_conflicting=True,
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 782,
> in resolve
> replace_conflicting=replace_conflicting
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1065,
> in best_match
> return self.obtain(req, installer)
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1077,
> in obtain
> return installer(requirement)
> File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 777, in
> fetch_build_egg
> return fetch_build_egg(self, req)
> File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 70, in
> fetch_build_egg
> return _legacy_fetch_build_egg(dist, req)
> File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 53, in
> _legacy_fetch_build_egg
> return cmd.easy_install(req)
> File "/usr/lib/python3/dist-packages/setuptools/command/easy_install.py",
> line 704, in easy_install
> raise DistutilsError(msg)
> distutils.errors.DistutilsError: Could not find suitable distribution for
> Requirement.parse('Sphinx~=1.8.1')
> E: pybuild pybuild:352: clean: plugin distutils failed with: exit code=1:
> python3.7 setup.py clean
> dh_auto_clean: error: pybuild --clean -i python{version} -p
Bug#955064: Simply allowing any version of Sphinx in setup.py fixes the problem
Hi Thomas, On Thu, Apr 30, 2020 at 11:03 PM Thomas Goirand wrote: > Attached debdiff fixes the issue. Can I NMU it? A bunch of the OpenStack > packages that I maintain will otherwise be auto-removed soon... Thanks, but I've the same in the queue. Uploading shortly not to risk your packages. Cheers, Laszlo/GCS
Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Jeffrey,
thanks a lot for this analysis. Any chance that somebody could
turn this into a patch I could try?
Kind regards
Andreas.
On Thu, Apr 30, 2020 at 03:40:12PM -0400, Jeffrey Walton wrote:
> On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille wrote:
> > ...
> > So it seems the bus error occures somehow here:
> >
> >
> > https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346
>
> NewProgress is at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.c#L53.
> It uses a progress_t at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.h#L25.
>
> typedef struct {
> /* where to write to */
> FILE *prFile;
> /* prefix printed before each step */
> char *pcPrefix;
> bool bPrintCR;
> char pcLastLogMsg[1024];
> Stopwatch_t *prStopwatch;
> } progress_t;
>
> And stopwatch_t at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.h:
>
> struct stopwatch_s {
> time_t t0; /* Wall clock time, ANSI time() */
> #ifdef SRE_STRICT_ANSI
> clock_t cpu0; /* CPU time, ANSI clock()*/
> #else
> struct tms cpu0; /* CPU/system time, POSIX times()*/
> #endif
>
> double elapsed; /* elapsed time, seconds */
> double user; /* CPU time, seconds */
> double sys; /* system time, seconds */
> };
>
> There are your doubles that are likely the problem.
>
> And what do we have here at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.c#L276
> ...
>
> void
> StopwatchPVMPack(Stopwatch_t *w)
> {
> pvm_pkdouble(&(w->elapsed), 1, 1);
> pvm_pkdouble(&(w->user),1, 1);
> pvm_pkdouble(&(w->sys), 1, 1);
> }
> void
> StopwatchPVMUnpack(Stopwatch_t *w)
> {
> pvm_upkdouble(&(w->elapsed), 1, 1);
> pvm_upkdouble(&(w->user),1, 1);
> pvm_upkdouble(&(w->sys), 1, 1);
> }
>
> I can't track the trail any further. The source code is missing for
> pvm_pkdouble and pvm_upkdouble. I would be very suspect of
> pvm_pkdouble and pvm_upkdouble.
>
> Jeff
>
--
http://fam-tille.de
Bug#955064: Simply allowing any version of Sphinx in setup.py fixes the problem
Hi Laszlo, Attached debdiff fixes the issue. Can I NMU it? A bunch of the OpenStack packages that I maintain will otherwise be auto-removed soon... Cheers, Thomas Goirand (zigo) diff -Nru grpc-1.26.0/debian/changelog grpc-1.26.0/debian/changelog --- grpc-1.26.0/debian/changelog2020-03-21 18:23:30.0 +0100 +++ grpc-1.26.0/debian/changelog2020-04-30 22:49:57.0 +0200 @@ -1,3 +1,10 @@ +grpc (1.26.0-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Rebuild. + + -- Thomas Goirand Thu, 30 Apr 2020 22:49:57 +0200 + grpc (1.26.0-2) unstable; urgency=medium * Build with protobuf version 3.11.4 or later (closes: #946194). diff -Nru grpc-1.26.0/debian/patches/allow-any-sphinx.patch grpc-1.26.0/debian/patches/allow-any-sphinx.patch --- grpc-1.26.0/debian/patches/allow-any-sphinx.patch 1970-01-01 01:00:00.0 +0100 +++ grpc-1.26.0/debian/patches/allow-any-sphinx.patch 2020-04-30 22:49:57.0 +0200 @@ -0,0 +1,16 @@ +Description: Allow any version of sphinx +Author: Thomas Goirand +Forwarded: no +Last-Update: 2020-04-30 + +--- grpc-1.26.0.orig/setup.py grpc-1.26.0/setup.py +@@ -336,7 +336,7 @@ INSTALL_REQUIRES = ( + ) + + SETUP_REQUIRES = INSTALL_REQUIRES + ( +-'Sphinx~=1.8.1', ++'Sphinx', + 'six>=1.10', + ) if ENABLE_DOCUMENTATION_BUILD else () + diff -Nru grpc-1.26.0/debian/patches/series grpc-1.26.0/debian/patches/series --- grpc-1.26.0/debian/patches/series 2019-12-20 15:34:21.0 +0100 +++ grpc-1.26.0/debian/patches/series 2020-04-30 22:49:57.0 +0200 @@ -9,3 +9,4 @@ fix-protoc-path.patch add_grpc_libdir.patch unbreak_foreach.patch +allow-any-sphinx.patch
Bug#958515: marked as done (diamond-aligner breaks proteinortho autopkgtest on arm64: Error: wrong fromat)
Your message dated Thu, 30 Apr 2020 20:35:42 + with message-id and subject line Bug#958515: fixed in diamond-aligner 0.9.32-2 has caused the Debian Bug report #958515, regarding diamond-aligner breaks proteinortho autopkgtest on arm64: Error: wrong fromat 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.) -- 958515: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958515 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: diamond-aligner, proteinortho Control: found -1 diamond-aligner/0.9.31-1 Control: found -1 proteinortho/6.0.14+dfsg-1 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of diamond-aligner the autopkgtest of proteinortho fails on arm64 in testing when that autopkgtest is run with the binary packages of diamond-aligner from unstable. It passes when run with only packages from testing. In tabular form: passfail diamond-alignerfrom testing0.9.31-1 proteinortho from testing6.0.14+dfsg-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of diamond-aligner to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=diamond-aligner https://ci.debian.net/data/autopkgtest/testing/arm64/p/proteinortho/5105579/log.gz autopkgtest [14:23:33]: test run-unit-test: [--- * [1;32mProteinortho[0m with PoFF version 6.0.14 - An orthology detection tool * Detected 32 available CPU threads (adjust this with -cpus), Detected 'blastp+' version 2.9.0+ Checking input files. Checking test/C.faa... ok Checking test/C2.faa... ok Checking test/E.faa... ok Checking test/L.faa... ok Checking test/M.faa... ok [1;32m**Step 1**[0m Generating indices anyway (forced). Building database for 'test/C.faa' (109 sequences) Building database for 'test/E.faa' (72 sequences) Building database for 'test/L.faa' (40 sequences) Building database for 'test/M.faa' (40 sequences) Building database for 'test/C2.faa' (2 sequences) [1;32m**Step 2**[0m using blastp+ Running blast analysis: 0% (0/10) Running blast analysis: 100% (10/10) Running blast analysis: 80% (8/10) Running blast analysis: 10% (1/10) Running blast analysis: 20% (2/10) Running blast analysis: 30% (3/10) Running blast analysis: 40% (4/10) Running blast analysis: 50% (5/10) Running blast analysis: 60% (6/10) Running blast analysis: 70% (7/10) Running blast analysis: 90% (9/10) Running blast analysis: 100% (10/10) [OUTPUT] -> written to test_blastp.blast-graph [1;32m**Step 3**[0m Clustering by similarity (Proteinortho mode) using up to 96343.5 MB of memory (75% of total memory) and 32 cpu core(s). Adjust this behaviour with the -mem option. Reading test_blastp.blast-graph 5 species 113 paired proteins 148 bidirectional edges Clustering: 85.84% Clustering: 89.38% Clustering: 93.81% Clustering: 95.58% Clustering: 100.00% Done [OUTPUT] -> Orthologous groups are written to test_blastp.proteinortho.tsv You can extract the fasta files of each orthology group with 'proteinortho_grab_proteins.pl -tofiles test_blastp.proteinortho.tsv test/C.faa test/E.faa test/L.faa test/M.faa test/C2.faa' (Careful: This will generate a file foreach line in the file test_blastp.proteinortho.tsv). [OUTPUT] -> Orthologous pairs are written to test_blastp.proteinortho-graph [OUTPUT] -> Summary is written to test_blastp.proteinortho-graph.summary [OUTPUT] -> Orthologous groups are written to test_blastp.proteinortho.html [1;32mAll finished.[0m * [1;32mProteinortho[0m with PoFF version 6.0.14 - An orthology detection tool * Detected 32 available CPU threads (adjust this with -cpus), Detected 'blastp+' version 2.9.0+ Checking input files. Checking test/C.faa... test/C.faa 109 genes ok Checking test/C2.faa...
Bug#958090: marked as done (diamond-aligner 0.9.31-1 fails on architectures where char is unsigned)
Your message dated Thu, 30 Apr 2020 20:35:42 + with message-id and subject line Bug#958090: fixed in diamond-aligner 0.9.32-2 has caused the Debian Bug report #958090, regarding diamond-aligner 0.9.31-1 fails on architectures where char is unsigned 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.) -- 958090: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958090 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: diamond-aligner Version: 0.9.31-1 Severity: serious Tags: ftbfs Control: affects -1 src:proteinortho https://ci.debian.net/data/autopkgtest/testing/arm64/p/proteinortho/4965864/log.gz https://buildd.debian.org/status/package.php?p=proteinortho&suite=sid ... make -j4 test make[1]: Entering directory '/<>' [TEST] Clean up all test files... [TEST] 1. basic proteinortho6.pl -step=2 test. (algorithms that are not present are skipped) [TEST] Clean up all test files... [1/12] -p=blastp+ test: passed [2/12] -p=blastp+ synteny (PoFF) test: tput: No value for $TERM and no -T specified [STDERR] Error: wrong fromat... Please make sure you only provide *.blast-graph or *.proteinortho-graph files as input... Died at .//src/BUILD/Linux_aarch64/proteinortho_summary.pl line 117, <$FH> line 2. USAGE: proteinortho2html.pl ( ...) the first argument points to the proteinortho output (tsv)-file. Any further (optional) files should be fasta files, for conversion of the identifier to a proper gene name/ describtion. The HTML output is printed to stdout, use '>' to write the html output to a file. passed [3/12] -p=diamond test: Parameter-vector : (version=6.0.15,step=0,verbose=0,debug=1,exactstep3=0,synteny=0,duplication=2,cs=3,alpha=0.5,connectivity=0.1,cpus=4,evalue=1e-05,purity=1e-07,coverage=50,identity=25,blastmode=diamond,sim=0.95,report=3,keep=0,force=1,selfblast=0,twilight=0,singles=0,clean=0,blastOptions=,nograph=0,xml=0,desc=0,tmp_path=./proteinortho_cache_test_diamond/,blastversion=unknown,binpath=,makedb=diamond makedb --in,blast=,jobs_todo=10,project=test_diamond,po_path=.//src/BUILD/Linux_aarch64,run_id=,threads_per_process=1,useMcl=0,freemem=-1) [1;31m[Error][0m [1;33m diamond failed. The most likely errorsources of this are: - no space left on device error. - outdated diamond, please update diamond or consider another -p algorithm. - the databases are missing. Maybe you ran --step=1 and removed the databases afterwards? Please rerun 'proteinortho --step=1 --force /path/to/fastas' - maybe the fasta files are mixed nucleotide and aminoacid sequences or just not suited for diamond? (For example diamond only processes protein sequences) Try 'proteinortho --step=1 --check --force /path/to/fastas'. [0m (If you cannot solve this error, please send a report to incoming+paulklemm-phd-proteinortho-7278443-iss...@incoming.gitlab.com including the parameter-vector above or visit https://gitlab.com/paulklemm_PHD/proteinortho/wikis/Error%20Codes for more help. Further more all mails to lech...@staff.uni-marburg.de are welcome) Perl exited with active threads: 3 running and unjoined 0 finished and unjoined 0 running and detached Error, could not open file test_diamond.proteinortho.tsv: No such file or directory at ./src/chk_test.pl line 6. make[1]: *** [Makefile:253: test_step2] Error 2 --- End Message --- --- Begin Message --- Source: diamond-aligner Source-Version: 0.9.32-2 Done: Andreas Tille We believe that the bug you reported is fixed in the latest version of diamond-aligner, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 958...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andreas Tille (supplier of updated diamond-aligner package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 30 Apr 2020 21:43:33 +0200 Source: diamond-aligner Architecture: source Version: 0.9.32-2 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team Changed-By: Andreas Tille Closes: 958090 958515 Changes: diamond-aligner (0.9.32-2) unstable; urgency=medium . * Fixed different build issues Closes: #958515, #958090 *
Bug#937431: pyepl: Python2 removal in sid/bullseye
On Thu, Apr 30, 2020 at 03:06:57PM -0400, Yaroslav Halchenko wrote: > > On Thu, 30 Apr 2020, Moritz Mühlenhoff wrote: > > > On Fri, Aug 30, 2019 at 07:33:35AM +, Matthias Klose wrote: > > > Package: src:pyepl > > > Version: 1.1.0+git12-g365f8e3-3 > > > Severity: normal > > > Tags: sid bullseye > > > User: debian-pyt...@lists.debian.org > > > Usertags: py2removal > > > > Python2 becomes end-of-live upstream, and Debian aims to remove > > > Python2 from the distribution, as discussed in > > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > > > Your package either build-depends, depends on Python2, or uses Python2 > > > in the autopkg tests. Please stop using Python2, and fix this issue > > > by one of the following actions. > > > pyepl is dead upstream, let's remove it? > > yes, AFAIK it is dead. Let's RM. you ? me ? ;) Please go ahead :-) Cheers, Moritz
Bug#958802: marked as done (gap-float: please update for new GAP ABI)
Your message dated Thu, 30 Apr 2020 19:48:45 + with message-id and subject line Bug#958802: fixed in gap-float 0.9.1+ds-6 has caused the Debian Bug report #958802, regarding gap-float: please update for new GAP ABI 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.) -- 958802: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958802 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- 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. --- End Message --- --- Begin Message --- Source: gap-float Source-Version: 0.9.1+ds-6 Done: Jerome Benoit We believe that the bug you reported is fixed in the latest version of gap-float, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 958...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jerome Benoit (supplier of updated gap-float package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 30 Apr 2020 19:35:44 + Source: gap-float Architecture: source Version: 0.9.1+ds-6 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Jerome Benoit Closes: 958802 Changes: gap-float (0.9.1+ds-6) unstable; urgency=medium . * Debianization: - debian/copyright: - copyright year tuple, update; - debian/control: - Maintainer address, update; - Rules-Requires-Root, introduce and set to no; - Depends field: - gap, bump to 4.11.0 ; - gapkernel:Depends substvars, introduce (Closes: #958802); - Standards Version, bump to 4.5.0 (no change). Checksums-Sha1: b50bdd16215d840a37552192a48ada176e55e1d1 2930 gap-float_0.9.1+ds-6.dsc 001a2460ecd037df784826b420e5514b2ab61aa4 7760 gap-float_0.9.1+ds-6.debian.tar.xz a4ac133ab6606aedc1bda09aecfcb2720bac4589 8842 gap-float_0.9.1+ds-6_source.buildinfo Checksums-Sha256: 450efb86a3c0db0856ef1d16cf2761cdfd64f5762f3e719a38b8586c16bf35ca 2930 gap-float_0.9.1+ds-6.dsc 84ee9eac4a37b7267a0dadaeb105d95d656e70ec3cd3484f34a9685dcf6c3051 7760 gap-float_0.9.1+ds-6.debian.tar.xz f52e4e806e89cae7519beccf4f8b3d1c1b5ede27e70ba5cb82d5c2fd042dca92 8842 gap-float_0.9.1+ds-6_source.buildinfo Files: a170c09c2af36cdc63eb775e0bf7cab2 2930 math optional gap-float_0.9.1+ds-6.dsc 28d0c67dae18f83b393dd84d4452279d 7760 math optional gap-float_0.9.1+ds-6.debian.tar.xz 36475f5e97ba20deab6f738b4d50e8e7 8842 math optional gap-float_0.9.1+ds-6_source.buildinfo -BEGIN PGP SIGNATURE- iQRJBAEBCgAzFiEEriiuFXEN/x2H5adiP5IZpn82xosFAl6rKVcVHGNhbGN1bHVz QHJlem96ZXIubmV0AAoJED+SGaZ/NsaLvOsgAKg8QxfxUeb7VYkNnNf7ko/Gd+en dJfFeXQUzKAqJDj88+yItbB0wG2iDt8GcDhqmota9P/q+1x+wUHpYEpaNPYSyM5b XOS+55Oj45rhqwCA8bRtXRZqs4obOAKdzgCfn7QPaHlnuUO40B2YnpnDgSiRljnc VfHjq+kAeruCfGNhKMThX4BSCv9RMVnU06vveO5nqA//wlp08MyqqGq9bQI1ewOa 0HYKDcKb3laCNA2HccCUZW2kbEo+2AeupP6fo2HWLycBcT9hsHuXpWXkMELWLeU3 dz3Ag+Wtchl3WQYrbSRz72insMMrHdbdXMECCxwrqv/o1jiohVEe/vykYR14yQoJ XqWECHevj7LVhnAalmmyvlP6Uh5HTawvAfw+d2JQxY/8xl3z/DBgIqPc/2D1XXf+ IyUrTKw/JzdGHTOxr0N7805jPiER/s4n6r22M3FfY9GcuEIDDuOIb2NUjzvqZvFK p5kYGryBWBDRLjal/N6BshPd9MTjKxY6b9GXlE+KewMa1HvhdOrsF09DWJy876kf sxkNdlO48NesmwLXlsxBgyFsE2WxTsAG0CF9GNvbdxB/eZfCKc0q8xzHpMWjChnz 8vqVhC2kOJ9TqRL/HtG0escJWyK2833l/QPeJCirIklOosU0EyGjfr9Pb66PMTE+ s57TtTXMT5qJkRv+/StgFT7vfthbzqxGMT5qL10oDVUjbDoePK5eeta/hQopm11I KSg/F+g1vYMUuBWbNnkjFIlp2O62tdGdoVGNd7E/RGAEDxCaqEiyhuz252ot6PVY NLvViu3rfjGWjvV/2mj+nd9/V2trvYIEwiJtb/nC/cUOVLsoql4ZREXSte+Vnd75 xkWwpLTT4ne+qwdAtXgrnIFTnjynFqfla+f8NqAXa2u/0k3VknY4jYcLhv2FttLW 5RsLliYFdfbWR5WRl48U/5ErD0bc1j1pP3uel3xk7z0rzQo3BkXQF4rx2GkAjWdL aIQyJ/vAvaV9Uib9qwEYXWoOavNhUFak5jo5aYzMGWC
Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille wrote:
> ...
> So it seems the bus error occures somehow here:
>
>
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346
NewProgress is at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.c#L53.
It uses a progress_t at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.h#L25.
typedef struct {
/* where to write to */
FILE *prFile;
/* prefix printed before each step */
char *pcPrefix;
bool bPrintCR;
char pcLastLogMsg[1024];
Stopwatch_t *prStopwatch;
} progress_t;
And stopwatch_t at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.h:
struct stopwatch_s {
time_t t0; /* Wall clock time, ANSI time() */
#ifdef SRE_STRICT_ANSI
clock_t cpu0; /* CPU time, ANSI clock()*/
#else
struct tms cpu0; /* CPU/system time, POSIX times()*/
#endif
double elapsed; /* elapsed time, seconds */
double user; /* CPU time, seconds */
double sys; /* system time, seconds */
};
There are your doubles that are likely the problem.
And what do we have here at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.c#L276
...
void
StopwatchPVMPack(Stopwatch_t *w)
{
pvm_pkdouble(&(w->elapsed), 1, 1);
pvm_pkdouble(&(w->user),1, 1);
pvm_pkdouble(&(w->sys), 1, 1);
}
void
StopwatchPVMUnpack(Stopwatch_t *w)
{
pvm_upkdouble(&(w->elapsed), 1, 1);
pvm_upkdouble(&(w->user),1, 1);
pvm_upkdouble(&(w->sys), 1, 1);
}
I can't track the trail any further. The source code is missing for
pvm_pkdouble and pvm_upkdouble. I would be very suspect of
pvm_pkdouble and pvm_upkdouble.
Jeff
Bug#958495: marked as done (gap-io: please update for new GAP ABI)
Your message dated Thu, 30 Apr 2020 19:34:19 + with message-id and subject line Bug#958495: fixed in gap-io 4.7.0+ds-2 has caused the Debian Bug report #958495, regarding gap-io: please update for new GAP ABI 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.) -- 958495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958495 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- 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. --- End Message --- --- Begin Message --- Source: gap-io Source-Version: 4.7.0+ds-2 Done: Jerome Benoit We believe that the bug you reported is fixed in the latest version of gap-io, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 958...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jerome Benoit (supplier of updated gap-io package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 30 Apr 2020 19:04:51 + Source: gap-io Architecture: source Version: 4.7.0+ds-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Jerome Benoit Closes: 958495 Changes: gap-io (4.7.0+ds-2) unstable; urgency=medium . * Debianization: - debian/copyright: - copyright year tuple, update; - debian/control: - Maintainer address, update; - Rules-Requires-Root, introduce and set to no; - Depends field: - gap, bump to 4.11.0 ; - gapkernel:Depends substvars, introduce (Closes: #958495); - Standards Version, bump to 4.5.0 (no change). Checksums-Sha1: 145f2afdb96df4bebeed85906af6d59d2053d549 2844 gap-io_4.7.0+ds-2.dsc f038f64bc07513d271fbac576bd1340f7f2cc4cb 6352 gap-io_4.7.0+ds-2.debian.tar.xz 09410a0503d33410f3f0cc218ce9098076d648fa 8661 gap-io_4.7.0+ds-2_source.buildinfo Checksums-Sha256: e4cdc175074187d774582c6b8283a6384ae17c1b79bd12fb4d31fe7b87824a36 2844 gap-io_4.7.0+ds-2.dsc 89e23f043f7d5b4f6e4b6a7069a4a7e34c42b9dd8719a1f42ee04e22da449145 6352 gap-io_4.7.0+ds-2.debian.tar.xz 0eafddfc78cb6483ed056dd0e267dade129e7e193856dd3602b071555148 8661 gap-io_4.7.0+ds-2_source.buildinfo Files: 7c5043ce612fff934e98ba4f613e3aa2 2844 math optional gap-io_4.7.0+ds-2.dsc 88730d5bc239f6dc1559d7a1c746f746 6352 math optional gap-io_4.7.0+ds-2.debian.tar.xz cd6d497707a189b6e8d7ca2e22237409 8661 math optional gap-io_4.7.0+ds-2_source.buildinfo -BEGIN PGP SIGNATURE- iQRJBAEBCgAzFiEEriiuFXEN/x2H5adiP5IZpn82xosFAl6rI+sVHGNhbGN1bHVz QHJlem96ZXIubmV0AAoJED+SGaZ/NsaLPngf/2w5FfB3glIk4JfvsesZ28zgtq81 dtpLKXH+SeysHugHQ5EA0cglTvZU5tRnb1i7MVUJiqZyD84eJH+s26ATj2r8+FJ0 N66oZ1DJQmo9r8WP3EnUaZKXo5yvuzPqbpI9mFdzXHXhB+XcviuB2F4A1Hu1xST2 a9sczJTssz29FVHHJaaPsY/0mey4PQzoOGcY9c2Bw2kLEqglkf1MX04UpN2FEQPM DLJdsDZiHBEvWPPXsnN8Aeno2mr22SaJb5k67tZ1HS4t8VYU9qCfWGyAJ54PMG30 TzI2u+Cx+UkdOBCu2V7/d9/OFgKqWN4L7h2u5d2k8tBbD6ZwEDLGmmd/Ckj/+snl vF+TDB52MtCJGvbeAvcztlJXa9IwN48AyK7fD8HJwV1BfGgvkgZwAWTOJc8uoywp ypPyUrXVGA6jtwvmaovrQAGeIb/Cgu2kGMtvjunYJpTjR9YMILskB3mLnqPBJWQJ Nb87oXRyfGAzs/LA1BCMgHXvSWcdT0BqGgKoA2uMH6jwpbIATOAE3urD9S66/rxb ldKrRNz0hdcd+f6ZzRWiereASe/7Mf0vdnbIw2GxLvg+LRbo2LYkq2hM4USib0C9 +UZ+bn/9ZwWfvZzqcRbNPEQHwL6DAwz2Rz1y02h2NLnME8ZlMBb4W+qO6I2z5Dju K3nUCnXLUOfI1Qvvy+Sp9X0HJDQ74l5H37Ez19SiRvliRXKB8t6bYRCbZ9nmtALB 45z9ieXG7eX6kNnD6ZL1IKuSQN7j7YbG4vhkHNoEFdsK5tM1joyGojfQ9j+BtgGz jkg4OCd3yPBMadtSkBoRAMnLhF17Q2nn8FnmXc3f+cQM1H4fnmRbmcUwpdIAMDZW bVqOZQb97zZcuy6HKD/9Q4hbpE+VY620XReNr1hRicTUPl6o69RcsGa756Ag7Jo0 1S249rGb8G+KSp/UlcjRDxJkicAV5kfE5Zdn9ytYeVnu5c4cNP2qFTH9qD8d4mux E7LWIY5mICFhJ0D2T1h4dDHQV4JfpUnFertW2o7LeEvYIdH/jiQSmhHxYTyVIPKq 8ir/WPf0EzEMxujlJ4K/s6F4HOskqwOTc
Bug#956371: marked as done (deal.ii: FTBFS with opencascade 7.4 (library transistion))
Your message dated Thu, 30 Apr 2020 19:33:48 +
with message-id
and subject line Bug#956371: fixed in deal.ii 9.1.1-10
has caused the Debian Bug report #956371,
regarding deal.ii: FTBFS with opencascade 7.4 (library transistion)
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.)
--
956371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956371
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: deal.ii
Version: 9.1.1
Severity: important
Control: tags -1 +patch
Control: block 956351 by -1
Dear Maintainer,
deal.ii FTBFS with the opencascade7.4, available in experimental.
The attached patch seems to fix that, at least here locally.
(It will still compile with the packages currently in sid)
Please also test your package against opencascade7.4 and let me know if you
have any issues with the newer version.
Cheers,
--
tobi
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- a/source/gmsh/utilities.cc
+++ b/source/gmsh/utilities.cc
@@ -76,7 +76,7 @@
dealii::OpenCASCADE::write_IGES(boundary, iges_file_name);
-ofstream geofile;
+std::ofstream geofile;
geofile.open(geo_file_name);
geofile << "Merge \"" << iges_file_name << "\";" << std::endl
<< "Line Loop (2) = {1};" << std::endl
--- End Message ---
--- Begin Message ---
Source: deal.ii
Source-Version: 9.1.1-10
Done: Tobias Frost
We believe that the bug you reported is fixed in the latest version of
deal.ii, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 956...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Tobias Frost (supplier of updated deal.ii package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Thu, 30 Apr 2020 21:01:44 +0200
Source: deal.ii
Architecture: source
Version: 9.1.1-10
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers
Changed-By: Tobias Frost
Closes: 956371
Changes:
deal.ii (9.1.1-10) unstable; urgency=medium
.
* Team upload.
* Apply patch to fix "FTBFS with opencascade 7.4 (Closes: #956371)
Checksums-Sha1:
f36404a186e680b04199831f1d6b5115a24b323c 2740 deal.ii_9.1.1-10.dsc
1429b7182ae442425509654dc3edb79aca55980a 10568 deal.ii_9.1.1-10.debian.tar.xz
cb0c3db47a6b451bd8d6bfcace0d6f25b2cc7f4c 8212 deal.ii_9.1.1-10_source.buildinfo
Checksums-Sha256:
483325c5af344ab8cfb4be8e30068b6fa4f15a497e831bfbecef1006431c6732 2740
deal.ii_9.1.1-10.dsc
43ab6d3c856d2ed74633ee20db7aecfbc831124c44e60a6dafd80836895a961d 10568
deal.ii_9.1.1-10.debian.tar.xz
005b35d4b4162bb38f62fcd2889f3c74629476a522b3f1c8fd31a6e47f9fcd3c 8212
deal.ii_9.1.1-10_source.buildinfo
Files:
894f6b01d2a6dc2c070bfac21fb8a001 2740 libs optional deal.ii_9.1.1-10.dsc
38b6dd464fda145a12db39efe8ca3259 10568 libs optional
deal.ii_9.1.1-10.debian.tar.xz
25de6d312138422c48a9ab9f06cd9d6c 8212 libs optional
deal.ii_9.1.1-10_source.buildinfo
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAl6rJDAACgkQkWT6HRe9
XTbg7A/9F9d+FB0iERUUv8jecBx0MSiaeRnLqozRADf6GnGCIm1pX4ZIf6S25MdT
jHiMigA3PcYLQE0lf1TCC9qzpeI5cYL/b4nz/lT8ad1duexNnq/EP5Xr0HwDC4Si
sgr2uOJEWZsWvWbofM2zoGigSnHleOZnwjBm/VGDyW5bzN9TOdW6RdspBbIWR2/+
89khrLRl0NtVF7gaC+GLDOH8bQ9Kmwm2ciggqU0WZd9opFfQzlQvCEOmCvKL4+Mg
BCf0+s0cL576CtTEtQlCPe4rFQkxkiPJWILAu8vgBWkrFoWquRw8qZdU1dp2XPRq
u5mw4jaUgmT1BA1cN+dUZgwo7SDFH2WQuN0Ld5ZAmlo6PlkkGZ6zl24evYDrlHs1
oTLwV9L2IBkX7ntSNBj2Jb9+oqqJP/KQwxfjLv+EOrqouhNZHZA+i66/R1Bh4All
x4cww2EysFgK5uwkLE4fU5tcBoTeEaWC3YG3YLwJIW9FNN1s0Lt1tmNNYVyi0sCx
yEOCyqCCEnK9m0AJyJBx8tjCDtBA97/T7q1sQzf8tCkcncp3O+FxpCywUgdtO/Yr
hqV0gew+Utg8e5Ruv7r/eL0GQ0sO9cS4hX0CM7GOLta7qOPrAmTINSubAbWOsM5J
xRGNZep5uKcc64DYiaPv
Bug#932197: Bug#937144: Request to join the Neurodebian group
On Thu, 30 Apr 2020, Moritz Mühlenhoff wrote: > On Wed, Feb 26, 2020 at 04:15:03PM +0100, Andreas Tille wrote: > > On Wed, Feb 26, 2020 at 08:37:30AM -0500, Yaroslav Halchenko wrote: > > > thank you Andreas!!! > > > re etelemetry&heudiconv: I made it optional for previous version of the > > > package: > > > $> quilt series > > > deb-no-demand-on-etelemetry > > > $> git describe > > > debian/0.6.0-1 > > Thanks for the hint. While this could possibly speet up the upload of > > nipype I for myself are fine with waiting for the new Build-Depends. > > Anybody who wants to speed up things is kindly invited to add this patch > > and upload. > What's the status here? python-etelemetry is now in the archive and testing. my problem with any version of nipype ended up stalling tests with python3.8. See e.g. https://github.com/nipy/nipype/pull/3154 for interactions with upstream and now a dedicated issue https://github.com/nipy/nipype/issues/3209 I guess what we could do is to upload currently present in debian version with python 3.8 testing disabled and hope for the best ;) I will exercise (update packaging and see if builds/test otherwise ok with 3.7 etc) that now Then we wait for python3-rdflib 5.0 being uploaded (just submitted a wishlist bug report to have it updated), and upload fresh snapshot (or release if by then done) of nipype. any suggestions to the plan? ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#937431: pyepl: Python2 removal in sid/bullseye
On Thu, 30 Apr 2020, Moritz Mühlenhoff wrote: > On Fri, Aug 30, 2019 at 07:33:35AM +, Matthias Klose wrote: > > Package: src:pyepl > > Version: 1.1.0+git12-g365f8e3-3 > > Severity: normal > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > > Python2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > > in the autopkg tests. Please stop using Python2, and fix this issue > > by one of the following actions. > pyepl is dead upstream, let's remove it? yes, AFAIK it is dead. Let's RM. you ? me ? ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#958554: marked as done (beautifulsoup4: autopkgtest failure.)
Your message dated Thu, 30 Apr 2020 19:03:26 +
with message-id
and subject line Bug#958554: fixed in beautifulsoup4 4.9.0-2
has caused the Debian Bug report #958554,
regarding beautifulsoup4: autopkgtest failure.
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.)
--
958554: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958554
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: beautifulsoup4
Version: 4.9.0-1
Severity: serious
The autopkgtest for beautifulsoup4 is failing in both plain unstable tests and
testing migration tests, but not in plain testing tests.
ERROR: test_dangling_combinator (bs4.tests.test_tree.TestSoupSelector)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/bs4/tests/test_tree.py", line 2268, in
test_dangling_combinator
self.assertRaises(SyntaxError, self.soup.select, 'h1 >')
File "/usr/lib/python3.8/unittest/case.py", line 816, in assertRaises
return context.handle('assertRaises', args, kwargs)
File "/usr/lib/python3.8/unittest/case.py", line 202, in handle
callable_obj(*args, **kwargs)
File "/usr/lib/python3/dist-packages/bs4/element.py", line 1831, in select
results = soupsieve.select(selector, self, namespaces, limit, **kwargs)
File "/usr/lib/python3/dist-packages/soupsieve/__init__.py", line 98, in
select
return compile(select, namespaces, flags, **kwargs).select(tag, limit)
File "/usr/lib/python3/dist-packages/soupsieve/__init__.py", line 62, in
compile
return cp._cached_css_compile(pattern, namespaces, custom, flags)
File "/usr/lib/python3/dist-packages/soupsieve/css_parser.py", line 208, in
_cached_css_compile
CSSParser(pattern, custom=custom_selectors,
flags=flags).process_selectors(),
File "/usr/lib/python3/dist-packages/soupsieve/css_parser.py", line 1043, in
process_selectors
return self.parse_selectors(self.selector_iter(self.pattern), index, flags)
File "/usr/lib/python3/dist-packages/soupsieve/css_parser.py", line 977, in
parse_selectors
raise SelectorSyntaxError(
soupsieve.util.SelectorSyntaxError: Expected a selector at position 4
line 1:
h1 >
^
==
ERROR: test_invalid_multiple_select (bs4.tests.test_tree.TestSoupSelector)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/bs4/tests/test_tree.py", line 2299, in
test_invalid_multiple_select
self.assertRaises(SyntaxError, self.soup.select, ',x, y')
File "/usr/lib/python3.8/unittest/case.py", line 816, in assertRaises
return context.handle('assertRaises', args, kwargs)
File "/usr/lib/python3.8/unittest/case.py", line 202, in handle
callable_obj(*args, **kwargs)
File "/usr/lib/python3/dist-packages/bs4/element.py", line 1831, in select
results = soupsieve.select(selector, self, namespaces, limit, **kwargs)
File "/usr/lib/python3/dist-packages/soupsieve/__init__.py", line 98, in
select
return compile(select, namespaces, flags, **kwargs).select(tag, limit)
File "/usr/lib/python3/dist-packages/soupsieve/__init__.py", line 62, in
compile
return cp._cached_css_compile(pattern, namespaces, custom, flags)
File "/usr/lib/python3/dist-packages/soupsieve/css_parser.py", line 208, in
_cached_css_compile
CSSParser(pattern, custom=custom_selectors,
flags=flags).process_selectors(),
File "/usr/lib/python3/dist-packages/soupsieve/css_parser.py", line 1043, in
process_selectors
return self.parse_selectors(self.selector_iter(self.pattern), index, flags)
File "/usr/lib/python3/dist-packages/soupsieve/css_parser.py", line 937, in
parse_selectors
has_selector, sel = self.parse_combinator(
File "/usr/lib/python3/dist-packages/soupsieve/css_parser.py", line 766, in
parse_combinator
raise SelectorSyntaxError(
soupsieve.util.SelectorSyntaxError: The combinator ',' at postion 0, must have
a selector before it
line 1:
,x, y
^
==
ERROR: test_invalid_tag (bs4.tests.test_tree.TestSoupSelector)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/bs4/tests/test_tree.py", line 2021, in
test_invalid_tag
self.assertRaises(SyntaxError, self.soup.select, 'tag%t')
File "/usr/lib/python3.8/unittest/case.py", line 816, in assertRaises
return context.handle('assertRaises', args
Processed: Bug#958554 marked as pending in beautifulsoup4
Processing control commands: > tag -1 pending Bug #958554 [src:beautifulsoup4] beautifulsoup4: autopkgtest failure. Added tag(s) pending. -- 958554: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958554 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#958554: marked as pending in beautifulsoup4
Control: tag -1 pending Hello, Bug #958554 in beautifulsoup4 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/modules/beautifulsoup4/-/commit/2afce5c496e55db86d93f178bb2597e8af113df9 Fix test failures with soupsieve 2.0. (Closes: #958554) (this message was generated automatically) -- Greetings https://bugs.debian.org/958554
Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille wrote: > > Control: tags -1 help > > as it can be seen on the recent build log of clustalo on mips[1] the > build fails with > > # Run additional test from python-biopython package to verify that > # this will work as well > src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out > temp_test.dnd -o temp_test.aln --outfmt clustal --force > make[1]: *** [debian/rules:25: override_dh_auto_test-arch] Bus error You can sometimes locate a bus error at build time with -Wcast-align. At runtime you can usually locate them with -fsanitize=undefined. On x86 -Wcast-align usually triggers when casting to/from floats and doubles. I don't know what triggers on MIPS, bit it may include integers. You should look for all calls that perform casts to/from void* and uint8_t* with a dereference. I.e., uint8_t y[8] = ...; double x = *(double*)y; If MIPS is sensitive to alignment (beyond x86 slop), then something like this will get you into trouble, too: uint8_t y[8] = ...; unsigned long x = *(unsigned long*)y; I don't know about MIPS, but... I've experienced the problem with long's on SPARCv8. SPARCv8 needs 8-byte alignments because they have a specialized 64-bit move instruction. Or SPARCv8 needs an extra compile/link switch that disables the 64-bit move. The option is -xmemalign, which tells the toolchain what alignments can be assumed. Jeff
Processed: Re: Bug#958554: beautifulsoup4: autopkgtest failure.
Processing control commands: > forwarded -1 https://bugs.launchpad.net/beautifulsoup/+bug/1872279 Bug #958554 [src:beautifulsoup4] beautifulsoup4: autopkgtest failure. Set Bug forwarded-to-address to 'https://bugs.launchpad.net/beautifulsoup/+bug/1872279'. -- 958554: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958554 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#958554: beautifulsoup4: autopkgtest failure.
Control: forwarded -1 https://bugs.launchpad.net/beautifulsoup/+bug/1872279 > From diffing test logs I belive this was most-likely caused by the > update to python-soupsieve Yep. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#959110: we need to run more scripts in Makefile than just gulp build
at least packages/babel-plugin-transform-runtime/scripts/build-dist.js should be run during build to fix this. I think it is safer to run make build.
Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
On Thu, Apr 30, 2020 at 10:33 AM Matthew Fernandez wrote: > > > On Apr 30, 2020, at 00:31, Andreas Tille wrote: > > > > On Wed, Apr 29, 2020 at 05:51:26PM -0700, Matthew Fernandez wrote: > > > >> The other option I suggested was Valgrind, but if you can’t run apt-file > >> you probably can’t install Valgrind either. > > > > Well, I guess apt-get is permitted for sudo but not apt-file. So I can > > probably install valgrind inside the chroot environment. I've never > > worked with valgrind. What am I supposed to do? > > Valgrind, in its default mode, checks for a variety of memory issues > (use-after-free, write out-of bounds, …). You don’t need any special > configure/build options, but you probably want to enable debug symbols > (`export CFLAGS=-g; export CXXFLAGS=-g`). Then you can prefix the test you’re > running with Valgrind: `valgrind ./src/clustalo -i > debian/tests/biopython_testdata/f002 …`. One small issue... Valgrind recommends -O0 or -O1: Compile your program with -g to include debugging information so that Memcheck's error messages include exact line numbers. Using -O0 is also a good idea, if you can tolerate the slowdown. With -O1 line numbers in error messages can be inaccurate, although generally speaking running Memcheck on code compiled at -O1 works fairly well, and the speed improvement compared to running -O0 is quite significant. Use of -O2 and above is not recommended as Memcheck occasionally reports uninitialised-value errors which don't really exist. Also see the Valgrind Quick Start Guide, Section 2. Preparing Your Programs, at http://valgrind.org/docs/manual/QuickStart.html. Jeff
Bug#959202: src:php-defaults: fails to migrate to testing for too long
Source: php-defaults Version: 73 Severity: serious Control: close -1 75 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 958423 958424 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:php-defaults has been trying to migrate since 2020-02-21 [2]. Hence, I am filing this bug. 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 bullseye, so it doesn't affect (old-)stable. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=php-defaults signature.asc Description: OpenPGP digital signature
Processed: src:php-defaults: fails to migrate to testing for too long
Processing control commands:
> close -1 75
Bug #959202 [src:php-defaults] src:php-defaults: fails to migrate to testing
for too long
Marked as fixed in versions php-defaults/75.
Bug #959202 [src:php-defaults] src:php-defaults: fails to migrate to testing
for too long
Marked Bug as done
> block -1 by 958423 958424
Bug #959202 {Done: Paul Gevers } [src:php-defaults]
src:php-defaults: fails to migrate to testing for too long
959202 was not blocked by any bugs.
959202 was not blocking any bugs.
Added blocking bug(s) of 959202: 958423 and 958424
--
959202: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959202
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#959201: jami-daemon: dring does not start due to a symbol lookup error
Package: jami-daemon Version: 20190215.1.f152c98~ds1-1+b1 Severity: grave Justification: renders package unusable Hi, Jami fails to connect to its daemon dring because it cannot start due to a symbol lookup error: /usr/lib/ring/dring: symbol lookup error: /usr/lib/ring/dring: undefined symbol: _ZN4YAML6detail9node_data12empty_scalarB5cxx11E Cheers, Bruno -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.utf-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.utf-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages jami-daemon depends on: ii libargon2-10~20171227-0.2 ii libasound2 1.2.2-2.1 ii libavcodec58 7:4.2.2-1+b1 ii libavdevice58 7:4.2.2-1+b1 ii libavfilter7 7:4.2.2-1+b1 ii libavformat58 7:4.2.2-1+b1 ii libavutil567:4.2.2-1+b1 ii libc6 2.30-4 ii libdbus-c++-1-0v5 0.9.0-8.1 ii libgcc-s1 [libgcc1]10-20200418-1 ii libgcc11:10-20200418-1 ii libgnutls303.6.13-2 ii libixml10 1:1.8.4-2 ii libjsoncpp11.7.4-3.1 ii libnatpmp1 20150609-7+b2 ii libnettle7 3.5.1+really3.5.1-2 ii libpcre3 2:8.39-12+b1 ii libpulse0 13.0-5 ii librestbed0 [librestbed0] 4.0~dfsg1-5 ii libsecp256k1-0 0.1~20170810-2 ii libstdc++6 10-20200418-1 ii libswresample3 7:4.2.2-1+b1 ii libswscale57:4.2.2-1+b1 ii libudev1 245.5-2 ii libupnp13 1:1.8.4-2 ii libuuid1 2.34-0.1 ii libyaml-cpp0.6 0.6.3-1 ii zlib1g 1:1.2.11.dfsg-2 jami-daemon recommends no packages. jami-daemon suggests no packages. -- no debconf information
Bug#950619: marked as done (dbus-c++ build depends on the removed libecore-dev)
Your message dated Thu, 30 Apr 2020 18:03:40 + with message-id and subject line Bug#950619: fixed in dbus-c++ 0.9.0-8.2 has caused the Debian Bug report #950619, regarding dbus-c++ build depends on the removed libecore-dev 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.) -- 950619: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950619 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: dbus-c++ Version: 0.9.0-8.1 Severity: serious Tags: ftbfs bullseye sid libecore-dev is no longer built by src:efl --- End Message --- --- Begin Message --- Source: dbus-c++ Source-Version: 0.9.0-8.2 Done: Peter Michael Green We believe that the bug you reported is fixed in the latest version of dbus-c++, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 950...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Peter Michael Green (supplier of updated dbus-c++ package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 30 Apr 2020 17:10:39 + Source: dbus-c++ Architecture: source Version: 0.9.0-8.2 Distribution: unstable Urgency: medium Maintainer: Vincent Cheng Changed-By: Peter Michael Green Closes: 950619 Changes: dbus-c++ (0.9.0-8.2) unstable; urgency=medium . * Non-maintainer upload. * Change build-dependency from obsolete libecore-dev to libefl-all-dev (Closes: 950619) Checksums-Sha1: efe0a24b4bddeab5ec6e82c4c4b99f88e120d5b3 2406 dbus-c++_0.9.0-8.2.dsc 4bd8964d2ec8cc3e1e0479198fbe7a9e7c6c4d92 7220 dbus-c++_0.9.0-8.2.debian.tar.xz b4f5ef4d161503e4e21d73f82c8f1a763b52110c 18257 dbus-c++_0.9.0-8.2_source.buildinfo Checksums-Sha256: 1c04da6d2081700864d602038750a86f706048900188431d3ca3ca88e103 2406 dbus-c++_0.9.0-8.2.dsc 42c5db331d7aa4d0758ff34c6815920b41ae17eaf0a0cfe53f636447d1d48e85 7220 dbus-c++_0.9.0-8.2.debian.tar.xz d90ed8ede16934e0662457df55ae21588662ee8178ccb0ec32f442844de880ff 18257 dbus-c++_0.9.0-8.2_source.buildinfo Files: 743d7c28232b9bbdabf5cae989c2e2f8 2406 libs optional dbus-c++_0.9.0-8.2.dsc 7f51712adecc107a04ca67eb746a70c4 7220 libs optional dbus-c++_0.9.0-8.2.debian.tar.xz 4b5eae8c57e4f8186c6b2ab01b2b934a 18257 libs optional dbus-c++_0.9.0-8.2_source.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEEU0DQATYMplbjSX63DEjqKnqP/XsFAl6rDnEUHHBsdWd3YXNo QGRlYmlhbi5vcmcACgkQDEjqKnqP/XtDiQ/8CBC1psWhgU7UzBBaltYR4ITlOyN6 M8sYB780FLLkubKFZJeoq0mX5MGYH9F2S3afeubiSuWjwUv2zVo3MoMvrsAc2Q4H oy4Q/yZ099zMZWzSfv1ZH5AcEAmPt7A9lZhAq58Df3iHKrpzvvhcRyiXfh68RttI EuHxRNtZkZZNPQGNPbL7AXo1pzlK11i9mjl1qtWQe9cpFOEZdT4njFsk1GGOvYVf htug6v4onhFldX359XX4XPbYkr9iWVSjTGMCJ56O7OnBV9jGHv0dtDMLlZ6iFHUx F7hl/VA9GMxtYCgHdLJCbL34NRG4dbs1CHEsKiaAC1rSZpLgOhVAzNhbQyISQqHU irDRoS6pS3I+E9DU/t04nef/NiDZnDMW+69nYk/gxZJazW330YotpJsDHY/A1voy Ff+NuwpeXuZS9nr18Yhzl8MPrZqYGYZpVX5q5oIHyK7+C1szsDd6DA3zdtcMn92C vQM+s0DeMZL6EjOHU1oIbKlk/tFfmrl2movTeWWPh4DtHXzECxqlykGkn6u/z4xb UmjR+L5VmugYkhIChUrzKoBVAmEa3ff826cdkGkw1TKtqQqhkVLkE2IQXh7GrnQv VU3l/C2jfnIKEdx9b6AxKGP42OkZzF5XDTvqBBflmd41YdUBYORS+gwjl8sJSIXu BszFiV7302e5LgI= =91LP -END PGP SIGNATURE End Message ---
Bug#951947: marked as done (decopy: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.8 3.7" returned exit code 13)
Your message dated Thu, 30 Apr 2020 18:03:45 +
with message-id
and subject line Bug#951947: fixed in decopy 0.2.4.2-1
has caused the Debian Bug report #951947,
regarding decopy: FTBFS: dh_auto_test: error: pybuild --test -i python{version}
-p "3.8 3.7" returned exit code 13
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.)
--
951947: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951947
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: decopy
Version: 0.2.4.1-2
Severity: serious
Justification: FTBFS on amd64
Tags: buster sid
Usertags: ftbfs-20200222 ftbfs-buster
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> LC_ALL=C.UTF-8 dh_auto_test
> I: pybuild base:217: python3.8 setup.py test
> running test
> WARNING: Testing via this command is deprecated and will be removed in a
> future version. Users looking for a generic test entry point independent of
> test runner are encouraged to use tox.
> running egg_info
> creating Decopy.egg-info
> writing Decopy.egg-info/PKG-INFO
> writing dependency_links to Decopy.egg-info/dependency_links.txt
> writing entry points to Decopy.egg-info/entry_points.txt
> writing top-level names to Decopy.egg-info/top_level.txt
> writing manifest file 'Decopy.egg-info/SOURCES.txt'
> reading manifest file 'Decopy.egg-info/SOURCES.txt'
> writing manifest file 'Decopy.egg-info/SOURCES.txt'
> running build_ext
> WARNING:root:command exiftool not found, using generic parser as fallback
> testCleanComments (tests.matchers_test.TestMatchers) ... ok
> testParseBsd (tests.matchers_test.TestMatchers) ... ok
> testParseCCBY (tests.matchers_test.TestMatchers) ... ok
> testParseCopyright (tests.matchers_test.TestMatchers) ... ok
> testParseGFDL (tests.matchers_test.TestMatchers) ... ok
> testParseGPL (tests.matchers_test.TestMatchers) ... ok
> testParseHolders (tests.matchers_test.TestMatchers) ... ok
> testParseHoldersMultiline (tests.matchers_test.TestMatchers) ... ok
> testParseHoldersMultilineYears (tests.matchers_test.TestMatchers) ... ok
> testParseLGPL (tests.matchers_test.TestMatchers) ... ok
> testParseLPPL (tests.matchers_test.TestMatchers) ... ok
> testParseMIT (tests.matchers_test.TestMatchers) ... ok
> testParseZPL (tests.matchers_test.TestMatchers) ... ok
> testAddTwoPeople (tests.tree_test.TestCopyrightGroup) ... ok
> testMergeEmails (tests.tree_test.TestCopyrightGroup) ... ok
> testMergeNames (tests.tree_test.TestCopyrightGroup) ... ok
> testMergeNamesWithYears (tests.tree_test.TestCopyrightGroup) ... ok
> testMergeYears (tests.tree_test.TestCopyrightGroup) ... ok
> testCommonPathEmpty (tests.tree_test.TestFileGroup) ... ok
> testCommonPathOneDirTwoFiles (tests.tree_test.TestFileGroup) ... ok
> testCommonPathOneFile (tests.tree_test.TestFileGroup) ... ok
> testGetPatternsEmptyGroup (tests.tree_test.TestFileGroup) ... ok
> testGetPatternsOneDirOneFile (tests.tree_test.TestFileGroup) ... ok
> testGetPatternsOneFile (tests.tree_test.TestFileGroup) ... ok
> testGetPatternsRoot (tests.tree_test.TestFileGroup) ... ok
> testGetPatternsSeparateGroups (tests.tree_test.TestFileGroup) ... ok
> testGetPatternsSeparateGroupsMoreFiles (tests.tree_test.TestFileGroup) ... ok
> testFullname (tests.tree_test.TestFileInfo) ... ok
> testGetLicenses (tests.tree_test.TestFileInfo) ... ok
> testIncluded (tests.tree_test.TestFileInfo) ... ok
> testSplittingPath (tests.tree_test.TestFileInfo) ... ok
> testTally (tests.tree_test.TestFileInfo) ... ok
> testCopyrightedTree (tests.tree_test.TestRootInfo)
> Parses a tree with licensed & copyrighted files (testdata/two). ...
> testDebianizedTree (tests.tree_test.TestRootInfo)
> Parses a tree that contains a debian/copyright (testdata/three). ...
> /usr/lib/python3/dist-packages/debian/copyright.py:654: UserWarning: Fixing
> Format URL
> warnings.warn('Fixing Format URL')
> ok
> testSimpleTree (tests.tree_test.TestRootInfo)
> Parses a tree with licensed files (testdata/one). ... ok
> testTreeExclude (tests.tree_test.TestRootInfo)
> Parse a tree with an exclusion expresion (testdata/three). ... ok
> testProcessComplex (tests.dep5_test.TestCopyright)
> Parses a debian/copyright with many entries (testdata/three). ... ok
> testProcessEmpty (tests.dep5_test.TestCopyright)
> Parses a tree with no debian/copyright file. ... ok
> testProcessMalformed (tests.dep5_test.TestCopyright)
> Parses a tree with a malformed debian/copyright file. ... ok
> testProcessSimple (tests.dep5_test.TestCopyright)
> Parses a debian/copyright with two
Bug#932197: Bug#937144: Request to join the Neurodebian group
On Wed, Feb 26, 2020 at 04:15:03PM +0100, Andreas Tille wrote: > On Wed, Feb 26, 2020 at 08:37:30AM -0500, Yaroslav Halchenko wrote: > > thank you Andreas!!! > > > > re etelemetry&heudiconv: I made it optional for previous version of the > > package: > > > > $> quilt series > > deb-no-demand-on-etelemetry > > > > $> git describe > > debian/0.6.0-1 > > Thanks for the hint. While this could possibly speet up the upload of > nipype I for myself are fine with waiting for the new Build-Depends. > Anybody who wants to speed up things is kindly invited to add this patch > and upload. What's the status here? python-etelemetry is now in the archive and testing. Cheers, Moritz
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On Mon, Apr 20, 2020 at 09:57:30AM +0200, Thomas Goirand wrote: > On 4/20/20 4:36 AM, peter green wrote: > > Funcsigs is a backport of the PEP 362 function signature features from > Python 3.3's inspect module. Python 2 has never been removed from this > package. Though instead, we shall remove this source package entirely > from Debian. > > Traceback2 *already* has Python 2 support removed in Sid. I uploaded > this on the 21st of march, pressured by its potential autoremoval. > > > If the maintainers of nipype are willing to upload a python 3 version > > soon, then option 1 is IMO the preffered way forward, but a new upstream > > version is not something I would be prepared to NMU. > > There's no other choice but to fix nipype at this point, or wait until > it gets autoremoved from Testing. IMO, it'd be fine to NMU a new > upstream release if you contact the current maintainer and/or using the > delayed queue. JFTR, nipype is removed from testing since August last year, so this is totally not a blocker :-) Cheers, Moritz
Bug#937431: pyepl: Python2 removal in sid/bullseye
On Fri, Aug 30, 2019 at 07:33:35AM +, Matthias Klose wrote: > Package: src:pyepl > Version: 1.1.0+git12-g365f8e3-3 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests. Please stop using Python2, and fix this issue > by one of the following actions. pyepl is dead upstream, let's remove it? Cheers, Moritz
Bug#950619: dbus-c++ build depends on the removed libecore-dev
Looking at the changelog for efl, the maintainer decided to give up on dev packages for the individual libraries and only provide one dev package ( libefl-all-dev ) for all the efl libraries. Transitional packages were provided for the buster release, but have now been dropped in bullseye/sid. Thus the thing to do here is to change the build-dependency from libecore-dev to libefl-all-dev . I made this change locally and it test-built succesfully. I have decided to go ahead with a NMU and per the NMU guidelines to do so without delay. A debdiff is attatched to this mail. diff -Nru dbus-c++-0.9.0/debian/changelog dbus-c++-0.9.0/debian/changelog --- dbus-c++-0.9.0/debian/changelog 2018-01-27 00:08:15.0 + +++ dbus-c++-0.9.0/debian/changelog 2020-04-30 17:10:39.0 + @@ -1,3 +1,11 @@ +dbus-c++ (0.9.0-8.2) unstable; urgency=medium + + * Non-maintainer upload. + * Change build-dependency from obsolete libecore-dev to libefl-all-dev +(Closes: 950619) + + -- Peter Michael Green Thu, 30 Apr 2020 17:10:39 + + dbus-c++ (0.9.0-8.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru dbus-c++-0.9.0/debian/control dbus-c++-0.9.0/debian/control --- dbus-c++-0.9.0/debian/control 2015-08-21 06:38:59.0 + +++ dbus-c++-0.9.0/debian/control 2020-04-30 17:10:39.0 + @@ -11,7 +11,7 @@ dpkg-dev (>= 1.16.1), graphviz, libdbus-1-dev (>= 0.60), - libecore-dev, + libefl-all-dev, libexpat1-dev, libglib2.0-dev, libgtkmm-2.4-dev (>= 1:2.24.4-2~),
Bug#952689: libcddb2: freedb service is closing down
On Thu, 27 Feb 2020 16:19:48 +0100 Andreas Ronnquist wrote:> Package: libcddb2 > Version: 1.3.2-6+b1 > Severity: important > > Dear Maintainer, > > According to a notice on https://freedb.org, that service is closing > down. I assume that libcddb is using that server, and only that - > please inform me if I am mistaken. I'm not the maintainer, but according to libccdb's documentataion it does use freedb.org as the default server, *but* it can also be used with other compatible servers. http://libcddb.sourceforge.net/API/cddb__conn_8h.html#54641c0dac5234713f1916d8d70d8e8b Afaik gnudb.org should be such a compatible server.
Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
On Thu, Apr 30, 2020 at 07:17:50AM -0700, Matthew Fernandez wrote: > > Valgrind, in its default mode, checks for a variety of memory issues > (use-after-free, write out-of bounds, …). You don’t need any special > configure/build options, but you probably want to enable debug symbols > (`export CFLAGS=-g; export CXXFLAGS=-g`). Then you can prefix the test you’re > running with Valgrind: `valgrind ./src/clustalo -i > debian/tests/biopython_testdata/f002 …`. Running on mipsel: (sid_mipsel-dchroot)tille@eller:~/clustalo$ valgrind src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force ==15149== Memcheck, a memory error detector ==15149== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==15149== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==15149== Command: src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force ==15149== ==15149== Conditional jump or move depends on uninitialised value(s) ==15149==at 0x4007828: cached_fpabi_reject_phdr_p (dl-machine-reject-phdr.h:57) ==15149==by 0x4007828: elf_machine_reject_phdr_p (dl-machine-reject-phdr.h:217) ==15149==by 0x4008080: open_verify.constprop.0 (dl-load.c:1688) ==15149==by 0x4009D7C: _dl_map_object (dl-load.c:2181) ==15149==by 0x40011F8: map_doit (rtld.c:607) ==15149==by 0x401B2A8: _dl_catch_exception (dl-error-skeleton.c:196) ==15149==by 0x401B334: _dl_catch_error (dl-error-skeleton.c:215) ==15149==by 0x4001138: do_preload (rtld.c:778) ==15149==by 0x4002560: handle_preload_list (rtld.c:879) ==15149==by 0x4005B08: dl_main (rtld.c:1684) ==15149==by 0x401A094: _dl_sysdep_start (dl-sysdep.c:253) ==15149==by 0x400199C: _dl_start_final (rtld.c:447) ==15149==by 0x4001D44: _dl_start (rtld.c:539) ==15149== ==15149== Invalid read of size 1 ==15149==at 0x486F558: ??? (in /usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8) ==15149==by 0x486F5F0: ??? (in /usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8) ==15149== Address 0x4d655c5 is 0 bytes after a block of size 37 alloc'd ==15149==at 0x484B89C: malloc (in /usr/lib/mipsel-linux-gnu/valgrind/vgpreload_memcheck-mips32-linux.so) ==15149==by 0x126674: CkMalloc (util.c:83) ==15149==by 0x126864: CkStrdup (util.c:213) ==15149==by 0x1108F4: ConvertOldCmdline(int*, char***, int, char**) (main.cpp:358) ==15149==by 0x10FCDC: main (main.cpp:467) ==15149== ==15149== Invalid read of size 4 ==15149==at 0x1221B8: PairDistances (pair_dist.c:346) ==15149==by 0x114774: AlignmentOrder (clustal-omega.c:835) ==15149==by 0x115024: Align (clustal-omega.c:1221) ==15149==by 0x112EB4: MyMain (mymain.c:1192) ==15149==by 0x10FCF0: main (main.cpp:469) ==15149== Address 0x83b0 is not stack'd, malloc'd or (recently) free'd ==15149== ==15149== ==15149== Process terminating with default action of signal 10 (SIGBUS) ==15149==at 0x1221B8: PairDistances (pair_dist.c:346) ==15149==by 0x114774: AlignmentOrder (clustal-omega.c:835) ==15149==by 0x115024: Align (clustal-omega.c:1221) ==15149==by 0x112EB4: MyMain (mymain.c:1192) ==15149==by 0x10FCF0: main (main.cpp:469) ==15149== ==15149== HEAP SUMMARY: ==15149== in use at exit: 8,039 bytes in 34 blocks ==15149== total heap usage: 112 allocs, 78 frees, 77,811 bytes allocated ==15149== ==15149== LEAK SUMMARY: ==15149==definitely lost: 128 bytes in 2 blocks ==15149==indirectly lost: 0 bytes in 0 blocks ==15149== possibly lost: 0 bytes in 0 blocks ==15149==still reachable: 7,911 bytes in 32 blocks ==15149== suppressed: 0 bytes in 0 blocks ==15149== Rerun with --leak-check=full to see details of leaked memory ==15149== ==15149== Use --track-origins=yes to see where uninitialised values come from ==15149== For lists of detected and suppressed errors, rerun with: -s ==15149== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) Bus error Is this different from your tests on amd64? > > On the other hand: Is valgrind possibly able to uncover issues also > > on any other architecture? > > You mean if we were to use Valgrind to debug this on e.g. x86? In my own > experiments on amd64, both ASan and Valgrind found multiple issues in both > Clustal Omega and its dependency, argtable2. However I don’t believe any of > the remaining ones I was seeing after the last patches I sent you could be > causing the mipsel bus error; they were all memory leaks. Thanks again for your great support and the time you've spent. Kind regards Andreas. -- http://fam-tille.de
Processed: tagging 936251
Processing commands for cont...@bugs.debian.org: > tags 936251 - fixed-upstream Bug #936251 [src:bup] bup: Python2 removal in sid/bullseye Removed tag(s) fixed-upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 936251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936251 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#959193: libperl5i-perl: Test failures with Devel::Declare 0.006022-1
Source: libperl5i-perl
Version: 2.13.2-1
Severity: serious
Tags: upstream ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=131226
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
As noted on ci.d.n and in CPAN RT, libperl5i-perl is broken by the
recent updagrade of libdevel-declare-perl.
Couldn't find declarator 'func' at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Devel/Declare/Context/Simple.pm line 47.
Devel::Declare::Context::Simple::skip_declarator(perl5i::2::Signatures=HASH(0x55bdfacdc748))
called at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Devel/Declare/MethodInstaller/Simple.pm
line 62
Devel::Declare::MethodInstaller::Simple::parser(perl5i::2::Signatures=HASH(0x55bdfacdc748),
"func", 4, 1) called at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Devel/Declare/MethodInstaller/Simple.pm
line 25
Devel::Declare::MethodInstaller::Simple::__ANON__("func", 4) called at
/usr/lib/x86_64-linux-gnu/perl5/5.30/Devel/Declare.pm line 277
Devel::Declare::linestr_callback("const", "func", 4) called at
t/Meta/methods.t line 115
t/Meta/methods.t .
Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run
etc.
Cheers,
gregor
-BEGIN PGP SIGNATURE-
iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl6q98ZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaKThAAoaPibfxHkbZDHE8qNwRhy9BxzqDyApOxQizwPlKcpimPKpv4kbbC+9K9
nvTNUCDM5i3IlHTQG9V0/VwRzlX+sdpo8iGQj6UtDdGRt+BP85sewQU+HjFvpVBR
X3nD2jZmt0S/EWGiUVG65ld/6dBsaPZA63CkVtGzLHJ3h5ybsrDF1+9dQgARXRfM
/Mpdg0GMnCRZXNcAaXvddXHDYdJ//X2IW1cJwxnHzldmrSRAx5dHB0Nvdk+Inwne
IwO8VEgJOvMycKhtiyxQ13T/+4EB+R7qiwRBhV4/9eGTBQ4rfzT1AtQeez98gO1i
0warPeNN+Jxw2Htsg0O5qWG0KayTJSR2xzvBUvHEsc5gg096SHNcujbu6MN+CC8J
/jdOop5ioUIAZDyMJlufPEtvUK4pX6uPDCU9S3DeujuZdiLWl7wWn18P0cr7uGql
72wCGgsfREIhqe8KiN16dGbF14H6hucI2J7pDI1BjK4877whV3/WxZNgP9FF/8T4
/tUxZEOucvD/Hd9g+A/1Hnm4cvdZSPC2wpzWDXYos4ihMXsMwORC8j3nXlaaj5AS
OOwbzmBNQDwhXy3wa5hHII5q+7A55mSiKFWhtWmPYj20IK66/qEvup/N8UakwYl0
Pmqlqw1GETSx6858NsW0S3N7F9jfIgaSFbCYQXu+IgwBE3Qf8Is=
=ieDu
-END PGP SIGNATURE-
Bug#959189: bbswitch-dkms: fails to build for kernel 5.6.7
On Thu, 2020-04-30 at 17:14 +0200, Andreas Beckmann wrote: > Control: severity -1 serious > > On 30/04/2020 16.54, Giacomo Mulas wrote: > > ./include/linux/proc_fs.h:64:24: note: expected ‘const struct proc_ops *’ > > but argument is of type ‘struct file_operations *’ > > OK, another one of these ... I'll take care of it. > > > Andreas Hi, Note there's https://github.com/Bumblebee-Project/bbswitch/pull/196 Not merged yet, and I have not tested it. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#959189: bbswitch-dkms: fails to build for kernel 5.6.7
Processing control commands: > severity -1 serious Bug #959189 [bbswitch-dkms] bbswitch-dkms: fails to build for kernel 5.6.7 Severity set to 'serious' from 'important' -- 959189: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959189 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#951151: marked as done (polymake: test failure on mips64el)
Your message dated Thu, 30 Apr 2020 14:35:24 + with message-id and subject line Bug#951151: fixed in polymake 4.0r1-1 has caused the Debian Bug report #951151, regarding polymake: test failure on mips64el 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.) -- 951151: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951151 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: polymake Version: 4.0-2 Severity: serious Justification: FTBFS After building on mips64el, I get HOME=$(mktemp -p build -d) perl perl/polymake --script run_testcases --emacs-style polymake: WARNING: created private directory build/tmp.8rZQYU191i/.polymake [snip] [ /core/functions/Schemas/create_restrictive_schema ] 1 verifying: 1 OK [ /common/functions/Linear Algebra/det ] 1 2zsh: segmentation fault HOME=$(mktemp -p build -d) perl perl/polymake --script run_testcases My naive attempt to get a backtrace just got the following: rogram received signal SIGSEGV, Segmentation fault. 0x00fff786029c in _fmpz_poly_xgcd_modular () from /usr/lib/mips64el-linux-gnuabi64/libflint-2.5.2.so (gdb) bt #0 0x00fff786029c in _fmpz_poly_xgcd_modular () from /usr/lib/mips64el-linux-gnuabi64/libflint-2.5.2.so #1 0x00fff7860294 in _fmpz_poly_xgcd_modular () from /usr/lib/mips64el-linux-gnuabi64/libflint-2.5.2.so Backtrace stopped: frame did not save the PC It looks like it's flint related? -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-7-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages polymake depends on: ii libbliss2 0.73-2 ii libc6 2.28-10 ii libcdd0d094j-2 ii libgcc1 1:8.3.0-6 ii libgmp102:6.1.2+dfsg-4 ii libgmpxx4ldbl 2:6.1.2+dfsg-4 ii libgomp18.3.0-6 ii liblrs0 0.70-3 ii libmpfr64.0.2-1 ii libnormaliz33.6.3+ds-1 ii libpolymake-dev-common 3.2r4-4 ii libppl141:1.2-7 ii libstdc++6 8.3.0-6 ii libxml2 2.9.4+dfsg1-7+b3 ii ninja-build 1.8.2-1 ii polymake-common 3.2r4-4 Versions of packages polymake recommends: ii chromium 79.0.3945.130-1~deb10u1 ii gfan 0.6.2-2 ii graphviz 2.40.1-6 ii sketch 1:0.3.7-11 ii xdg-utils 1.1.3-1 Versions of packages polymake suggests: pn povray ii texlive-pictures 2018.20190227-2 -- no debconf information --- End Message --- --- Begin Message --- Source: polymake Source-Version: 4.0r1-1 Done: David Bremner We believe that the bug you reported is fixed in the latest version of polymake, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 951...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. David Bremner (supplier of updated polymake package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 30 Apr 2020 10:23:43 -0300 Source: polymake Architecture: source Version: 4.0r1-1 Distribution: unstable Urgency: medium Maintainer: David Bremner Changed-By: David Bremner Closes: 951137 951151 Changes: polymake (4.0r1-1) unstable; urgency=medium . * New upstream bugfix release * Bug fix: "test failure on mips64el", thanks to Benjamin Lorenz for the fix (Closes: #951151). * Upstream Bug fix: "FTBFS if terminal is unset", thanks to Gianfranco Costamagna (Closes: #951137). Checksums-Sha1: 9aab5c1e4d7974e4abfb48a215e1a9ecfb7d4b39 2536 polymake_4.0r1-1.dsc 2085d90e7deec47c4215d4ad1acfb3c0a4f7cc19 3724148 polymake_4.0r1.orig.tar.bz2 993b1c38a6789b5e8cda970e4e7d2d7beeb3a406 9928 polymake_4.0r1-1.debian.tar.xz Checksums-Sha256: 70952c41948875fb699ab8a3ba48781de23a4ed443976a370ef7af3063b22815 2536 polymake_4.
Processed: Re: Bug#956371: deal.ii: diff for NMU version 9.1.1-9.1
Processing control commands: > tags -1 + fixed-upstream Bug #956371 [src:deal.ii] deal.ii: FTBFS with opencascade 7.4 (library transistion) Added tag(s) fixed-upstream. -- 956371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956371 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#956371: deal.ii: diff for NMU version 9.1.1-9.1
Control: tags -1 + fixed-upstream Hi Tobias On Wed, 29 Apr 2020 at 21:39, Tobias Frost wrote: > I've prepared an NMU for deal.ii (versioned as 9.1.1-9.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. Mattias Maier pointed out this is already fixed upstream [1] in the same way. If I'm not mistaken, you are already a member of science-team on salsa. Please go ahead with a team upload. Regards Graham [1] https://github.com/dealii/dealii/commit/adb1281b842d5bd9c89e0483e25e5922ed08fdef
Bug#959089: marked as done (localslackirc: missing build dependencies on python3-requests and python3-websocket)
Your message dated Thu, 30 Apr 2020 14:34:03 + with message-id and subject line Bug#959089: fixed in localslackirc 1.9-2 has caused the Debian Bug report #959089, regarding localslackirc: missing build dependencies on python3-requests and python3-websocket 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.) -- 959089: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959089 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: localslackirc Version: 1.9-1 Severity: serious Tags: ftbfs https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/localslackirc.html ... dh_auto_test make -j16 test make[1]: Entering directory '/build/1st/localslackirc-1.9' MYPYPATH=stubs mypy --config-file mypy.conf irc.py Success: no issues found in 1 source file python3 -m tests Traceback (most recent call last): File "/usr/lib/python3.8/runpy.py", line 193, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/lib/python3.8/runpy.py", line 86, in _run_code exec(code, run_globals) File "/build/1st/localslackirc-1.9/tests/__main__.py", line 21, in from .test_re import * File "/build/1st/localslackirc-1.9/tests/test_re.py", line 21, in from irc import _MENTIONS_REGEXP, _CHANNEL_MENTIONS_REGEXP, _URL_REGEXP File "/build/1st/localslackirc-1.9/irc.py", line 38, in import slack File "/build/1st/localslackirc-1.9/slack.py", line 29, in from slackclient import SlackClient File "/build/1st/localslackirc-1.9/slackclient/__init__.py", line 1, in from .client import SlackClient File "/build/1st/localslackirc-1.9/slackclient/client.py", line 29, in from requests.packages.urllib3.util.url import parse_url ModuleNotFoundError: No module named 'requests' make[1]: *** [Makefile:10: test] Error 1 --- End Message --- --- Begin Message --- Source: localslackirc Source-Version: 1.9-2 Done: Salvo 'LtWorf' Tomaselli We believe that the bug you reported is fixed in the latest version of localslackirc, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 959...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Salvo 'LtWorf' Tomaselli (supplier of updated localslackirc package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 30 Apr 2020 15:56:23 +0200 Source: localslackirc Binary: localslackirc Architecture: source all Version: 1.9-2 Distribution: unstable Urgency: high Maintainer: Salvo 'LtWorf' Tomaselli Changed-By: Salvo 'LtWorf' Tomaselli Description: localslackirc - IRC gateway for slack, running on localhost for one user Closes: 959089 Changes: localslackirc (1.9-2) unstable; urgency=high . * Add needed build-deps (Closes: #959089) Checksums-Sha1: 0636cc6fb5ed1a959419faa9f12f75cce030ba99 2201 localslackirc_1.9-2.dsc cda0ddd81feef736bac84abccd804005fcaa7165 12520 localslackirc_1.9-2.debian.tar.xz b70173579895ca73e787663238fb4dec55afafa0 26348 localslackirc_1.9-2_all.deb 2e4132cf683bead915039a6df15a6632aae4c81f 7317 localslackirc_1.9-2_amd64.buildinfo Checksums-Sha256: d32324fd9299bd2e0e61ada662f4dc01475b7a3f2eae85da59101648b6639941 2201 localslackirc_1.9-2.dsc fea1e9cec211692904ccb6b507457f3939d6a17322725637efcc7b2f365c8ecf 12520 localslackirc_1.9-2.debian.tar.xz 9e174a0e2f591d99835b5841ce18d998fa7da46f6b25317d61a2182d4a864d79 26348 localslackirc_1.9-2_all.deb 844f7bb904c06ebc80931280529c68c2b3b963c0a0c9b0fd8b33d85c642ebb40 7317 localslackirc_1.9-2_amd64.buildinfo Files: 0d402f47df8a1839296b0f47e34cce9e 2201 net optional localslackirc_1.9-2.dsc 0cf94a40ff50c40f0884fce9f5edafd2 12520 net optional localslackirc_1.9-2.debian.tar.xz c6ceacaec9ef13e92e6ae1813a750b37 26348 net optional localslackirc_1.9-2_all.deb 231626f4f69891ee64ea1e7d98f1cab7 7317 net optional localslackirc_1.9-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEEQnSLnnbYmXmeH74Us6fPDIAYhs8FAl6q2qcUHHRpcG9zY2hp QHRpc2NhbGkuaXQACgkQs6fPDIAYhs+b5RAAgPQCcRy96UkamWA6Wrha1Y1d2ic4 87aNLdO0EBK416M6OsUNwX83Z9AQIpsxEiNKQ3wZT2sQrNO0c/yPemRGLagYjytE rOP2iuNwjAKoaVxUlWH/DsHomoHYQLrAQaOM+7MyQnaI0hU2B5/uYpBcdacAvfNv MRaFSaHJiBfPz3cKwULgi5HVgwfOwaogH0
Bug#959137: lasagne: (autopkgtest) needs update for new version of numpy: 'numpy.float64' object cannot be interpreted as an integer
The package has been updated in salsa and is awaiting sponsorship. regards, Steve On Wed, Apr 29, 2020 at 9:48 PM Paul Gevers wrote: > > Source: lasagne > Version: 0.1+git20181019.a61b76f-2 > Severity: serious > X-Debbugs-CC: debian...@lists.debian.org, nu...@packages.debian.org > Tags: sid bullseye > User: debian...@lists.debian.org > Usertags: needs-update > Control: affects -1 src:numpy > > Dear maintainer(s), > > With a recent upload of numpy the autopkgtest of lasagne fails in > testing when that autopkgtest is run with the binary packages of numpy > from unstable. It passes when run with only packages from testing. In > tabular form: > >passfail > numpy from testing1:1.18.3-1 > lasagnefrom testing0.1+git20181019.a61b76f-2 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of numpy to testing > [1]. Of course, numpy shouldn't just break your autopkgtest (or even > worse, your package), but it seems to me that the change in numpy was > intended and your package needs to update to the new situation. > > If this is a real problem in your package (and not only in your > autopkgtest), the right binary package(s) from numpy should really add a > versioned Breaks on the unfixed version of (one of your) package(s). > Note: the Breaks is nice even if the issue is only in the autopkgtest as > it helps the migration software to figure out the right versions to > combine in the tests. > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=numpy > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/lasagne/5197094/log.gz > > === FAILURES > === > > TestTPSTransformLayer.test_transform_thin_plate_spline_variable_input _ > > start = -1, stop = 1, num = 4.0, endpoint = True, retstep = False, dtype > = None > axis = 0 > > @array_function_dispatch(_linspace_dispatcher) > def linspace(start, stop, num=50, endpoint=True, retstep=False, > dtype=None, > axis=0): > """ > Return evenly spaced numbers over a specified interval. > > Returns `num` evenly spaced samples, calculated over the > interval [`start`, `stop`]. > > The endpoint of the interval can optionally be excluded. > > .. versionchanged:: 1.16.0 > Non-scalar `start` and `stop` are now supported. > > Parameters > -- > start : array_like > The starting value of the sequence. > stop : array_like > The end value of the sequence, unless `endpoint` is set to > False. > In that case, the sequence consists of all but the last of > ``num + 1`` > evenly spaced samples, so that `stop` is excluded. Note > that the step > size changes when `endpoint` is False. > num : int, optional > Number of samples to generate. Default is 50. Must be > non-negative. > endpoint : bool, optional > If True, `stop` is the last sample. Otherwise, it is not > included. > Default is True. > retstep : bool, optional > If True, return (`samples`, `step`), where `step` is the spacing > between samples. > dtype : dtype, optional > The type of the output array. If `dtype` is not given, > infer the data > type from the other input arguments. > > .. versionadded:: 1.9.0 > > axis : int, optional > The axis in the result to store the samples. Relevant only > if start > or stop are array-like. By default (0), the samples will be > along a > new axis inserted at the beginning. Use -1 to get an axis at > the end. > > .. versionadded:: 1.16.0 > > Returns > --- > samples : ndarray > There are `num` equally spaced samples in the closed interval > ``[start, stop]`` or the half-open interval ``[start, stop)`` > (depending on whether `endpoint` is True or False). > step : float, optional > Only returned if `retstep` is True > > Size of spacing between samples. > > > See Also > > arange : Similar to `linspace`, but uses a step size (instead of the > number of samples). > geomspace : Similar to `linspace`, but with numbers spaced > evenly on a log > scale (a geometric progression). > logspace : Similar to `geomspace`, but with the end points > specified as >logarithms. > > Examples > > >>> n
Bug#958446: nvidia-legacy-340xx-driver: Fails to build with kernel 5.6
Package: nvidia-legacy-340xx-driver Followup-For: Bug #958446 It works! I noticed that 5.6 reached unstable today, so I tried it asap. The driver compiles as it should, 3d acceleration works, vdpau works, even the temperatures work! Thank you for everything :) -- Package-specific info: uname -a: Linux mitsos 5.6.0-1-amd64 #1 SMP Debian 5.6.7-1 (2020-04-29) x86_64 GNU/Linux /proc/version: Linux version 5.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-11)) #1 SMP Debian 5.6.7-1 (2020-04-29) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 9.3.0 (Debian 9.3.0-10) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.155212] Console: colour VGA+ 80x25 [0.592472] pci :01:00.0: vgaarb: setting as boot VGA device [0.592472] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.592472] pci :01:00.0: vgaarb: bridge control possible [0.592472] vgaarb: loaded [0.777173] Linux agpgart interface v0.103 [3.188433] nvidia: loading out-of-tree module taints kernel. [3.188444] nvidia: module license 'NVIDIA' taints kernel. [3.215372] nvidia: module verification failed: signature and/or required key missing - tainting kernel [3.223898] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [3.240035] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0 [3.240055] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 [3.771106] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [3.861320] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input9 [3.861414] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input10 [3.861499] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11 [3.861585] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12 [8.957111] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs Device node permissions: crw-rw+ 1 root video 226, 0 Apr 30 17:10 /dev/dri/card0 crw-rw-rw- 1 root root 195, 0 Apr 30 17:11 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Apr 30 17:11 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Apr 30 17:10 pci-:01:00.0-card -> ../card0 video:*:44:jim OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jan 5 09:29 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 44 Jan 5 09:29 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 25 Jan 5 09:29 /etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jan 5 09:29 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jan 5 09:29 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 39 Jan 5 09:29 /etc/alternatives/glx--nvidia-drm-outputclass.conf -> /etc/nvidia/nvidia-drm-outputclass.conf lrwxrwxrwx 1 root root 28 Jan 5 09:29 /etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf lrwxrwxrwx 1 root root 32 Jan 5 09:29 /etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf lrwxrwxrwx 1 root root 29 Jan 5 09:29 /etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 28 Jan 5 09:27 /etc/alternatives/nvidia -> /usr/lib/nvidia/legacy-340xx lrwxrwxrwx 1 root root 57 Jan 5 09:27 /etc/alternatives/nvidia--libEGL.s
Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
> On Apr 30, 2020, at 00:31, Andreas Tille wrote: > > On Wed, Apr 29, 2020 at 05:51:26PM -0700, Matthew Fernandez wrote: > >> The other option I suggested was Valgrind, but if you can’t run apt-file you >> probably can’t install Valgrind either. > > Well, I guess apt-get is permitted for sudo but not apt-file. So I can > probably install valgrind inside the chroot environment. I've never > worked with valgrind. What am I supposed to do? Valgrind, in its default mode, checks for a variety of memory issues (use-after-free, write out-of bounds, …). You don’t need any special configure/build options, but you probably want to enable debug symbols (`export CFLAGS=-g; export CXXFLAGS=-g`). Then you can prefix the test you’re running with Valgrind: `valgrind ./src/clustalo -i debian/tests/biopython_testdata/f002 …`. Valgrind and ASan serve roughly the same purpose in this scenario, but I usually tend to prefer ASan because it is more efficient and tends to give you more accurate debugging clues. > On the other hand: Is valgrind possibly able to uncover issues also > on any other architecture? You mean if we were to use Valgrind to debug this on e.g. x86? In my own experiments on amd64, both ASan and Valgrind found multiple issues in both Clustal Omega and its dependency, argtable2. However I don’t believe any of the remaining ones I was seeing after the last patches I sent you could be causing the mipsel bus error; they were all memory leaks.
Processed: bug 954535 is forwarded to deve...@faert.net
Processing commands for cont...@bugs.debian.org: > forwarded 954535 deve...@faert.net Bug #954535 [src:guymager] guymager: FTBFS: aewf.cpp:143:12: error: flexible array member ‘::OffsetArr’ not at end of ‘struct’ Bug #957321 [src:guymager] guymager: ftbfs with GCC-10 Set Bug forwarded-to-address to 'deve...@faert.net'. Set Bug forwarded-to-address to 'deve...@faert.net'. > thanks Stopping processing here. Please contact me if you need assistance. -- 954535: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954535 957321: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957321 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#954762: systraq: Annoying as Hell
Processing commands for cont...@bugs.debian.org:
> severity 954762 normal
Bug #954762 {Done: Juhani Numminen } [systraq]
systraq: Annoying as Hell
Severity set to 'normal' from 'critical'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
954762: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954762
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#958446: nvidia-legacy-340xx-driver: Fails to build with kernel 5.6
DKMS works for me using kernel 5.6.8 -- sRw On 2020-04-30 06:09, Andreas Beckmann wrote: On 30/04/2020 12.09, jim_p wrote: And then the reference to #956458, which is for nvidia legacy 390xx. So I would like to ask if the bug I mentioned here is indeed fixed in the -5 revision of the package. I can't test it right now, but I probably will tomorrow or on Saturday. I backported NVIDIA's changes from 440.82 to 418.126.02 (tesla-418), then to 390.132 (legacy-390xx) then to 340.108 (copying the wrong bug number). There were always some parts being patched not yet existing in the older releases so the patches got smaller on the way. For 340.108 it was more or less a complete redo, since nvidia significantly restructured the driver source after that series. There were also some ancient bits no longer existing in newer releases that needed to be patched additionally for 5.6. So yes, it is fixed for the 340 series, too. But as always, only compile-tested. Andreas
Bug#958419: swi-prolog 8.1.29 in Debian
On 4/30/20 2:50 PM, Jonas Smedegaard wrote: Quoting Lev Lamberov (2020-04-30 14:40:53) Чт 30 апр 2020 @ 14:06 Jan Wielemaker : On 4/30/20 1:41 PM, Jonas Smedegaard wrote: I think we can use the format almost as-is - just replacing the leading "swipl-" with "swi-prolog-abi-". I think adding "abi" makes sense. I can replace "swipl" with the package name, which is "swi-prolog" for Debian. I'm thinking about something like as follows: Provides: swi-prolog-abi-$(swipl:ABI) where $(swipl:ABI) will be set in d/rules in override_dh_gencontrol target, so actually it doesn't matter what is the original output of swipl --abi_version, since we have sed and other tools to make it as we like. What do you think, Jonas? I agree with Lev. That is what I tried to say above as well (that we can _take_ it as-is and will need to massage it only slightly), but I see now that it can just as easily be read as meaning the opposite (that we would need a slightly different format). So to (try) clarify: I think it is *perfect* usable for Debian that upstream code emits "swipl-2-67-792e14f8-de23899e" when asked for its ABI. I did change it now to be $SWIPL_PKG_NAME-abi-*, where the default SWIPL_PKG_NAME is derived from $SWIPL_INSTALL_DIR if it contains something usable and "swipl" otherwise (some installations set this to "."). I don't think you care too much. Unless there is a real need to change I'll keep it that way. It is nicely informative. If you just want the numbers you can delete `^.*-abi-`. Cheers --- Jan Sorry for the confusion. - Jonas
Bug#958419: swi-prolog 8.1.29 in Debian
Чт 30 апр 2020 @ 14:56 Jan Wielemaker : > On 4/30/20 2:50 PM, Jonas Smedegaard wrote: >> Quoting Lev Lamberov (2020-04-30 14:40:53) >>> Чт 30 апр 2020 @ 14:06 Jan Wielemaker : >>> On 4/30/20 1:41 PM, Jonas Smedegaard wrote: > I think we can use the format almost as-is - just replacing the > leading "swipl-" with "swi-prolog-abi-". I think adding "abi" makes sense. I can replace "swipl" with the package name, which is "swi-prolog" for Debian. >>> >>> I'm thinking about something like as follows: >>> >>> Provides: swi-prolog-abi-$(swipl:ABI) >>> >>> where $(swipl:ABI) will be set in d/rules in override_dh_gencontrol >>> target, so actually it doesn't matter what is the original output of >>> swipl --abi_version, since we have sed and other tools to make it as >>> we like. What do you think, Jonas? >> >> I agree with Lev. That is what I tried to say above as well (that we >> can _take_ it as-is and will need to massage it only slightly), but I >> see now that it can just as easily be read as meaning the opposite (that >> we would need a slightly different format). >> >> So to (try) clarify: I think it is *perfect* usable for Debian that >> upstream code emits "swipl-2-67-792e14f8-de23899e" when asked for its >> ABI. > > I did change it now to be $SWIPL_PKG_NAME-abi-*, where the default > SWIPL_PKG_NAME is derived from $SWIPL_INSTALL_DIR if it contains > something usable and "swipl" otherwise (some installations set this > to "."). > > I don't think you care too much. Unless there is a real need to > change I'll keep it that way. It is nicely informative. If you > just want the numbers you can delete `^.*-abi-`. Sure, that's what we need. Thanks, Jan! Cheers! Lev
Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Quoting Jan Wielemaker (2020-04-30 14:40:58) > In theory we could have a package that merely contains /usr/bin/swipl > and /usr/lib/libswipl.so.8.2.0. That is enough to run saved states > (provided they have been built such that no dependencies need to be > loaded at runtime) and is indeed a lot smaller than swi-prolog-nox. > Possibly bundle these two as swi-prolog-runtime and make > swi-prolog-nox depend on it? > > A small problem is that running `swipl` will result in a big ugly > error message that it cannot find its startup resources. One could add > boot.prc to the runtime package which would allow running Prolog (but > without any library). > > I'm pretty neutral in this. Eye is for the time being the only use > case, but who knows there will be more :) Sounds elegant if that's possible. I will leave it to Lev to decide how fine- or coarse-grained to do the packaging of swi-prolog for Debian, as it will obviously affect the maintenance burden going forward as well, which will be mainly on him. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jonas, In theory we could have a package that merely contains /usr/bin/swipl and /usr/lib/libswipl.so.8.2.0. That is enough to run saved states (provided they have been built such that no dependencies need to be loaded at runtime) and is indeed a lot smaller than swi-prolog-nox. Possibly bundle these two as swi-prolog-runtime and make swi-prolog-nox depend on it? A small problem is that running `swipl` will result in a big ugly error message that it cannot find its startup resources. One could add boot.prc to the runtime package which would allow running Prolog (but without any library). I'm pretty neutral in this. Eye is for the time being the only use case, but who knows there will be more :) --- Jan
Processed: Re: scilab: FTBFS: Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available).
Processing control commands:
> found -1 5.5.2-4
Bug #955694 {Done: Julien Puydt } [src:scilab] scilab:
FTBFS: Scilab cannot create Scilab Java Main-Class (we have not been able to
find the main Scilab class. Check if the Scilab and thirdparty packages are
available).
Marked as found in versions scilab/5.5.2-4.
> found -1 6.0.1-10
Bug #955694 {Done: Julien Puydt } [src:scilab] scilab:
FTBFS: Scilab cannot create Scilab Java Main-Class (we have not been able to
find the main Scilab class. Check if the Scilab and thirdparty packages are
available).
Marked as found in versions scilab/6.0.1-10.
--
955694: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955694
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#955694: scilab: FTBFS: Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available).
Control: found -1 5.5.2-4 Control: found -1 6.0.1-10 Julien Puydt a écrit le 23/04/2020 à 09:37 : > Hi, > > Le jeudi 23 avril 2020 à 00:20 +0200, Gilles Filippini a écrit : >> Gilles Filippini a écrit le 22/04/2020 à 09:59 : >>> I think I've eventually found a fix for Scilab. Please hold. >> >> Here it is, attached. > > I'm checking it right now. Thanks for the upload. Could you please address this bug for stable-sec and old-stable as well? Thanks in advance, _g.
Bug#958419: swi-prolog 8.1.29 in Debian
Quoting Lev Lamberov (2020-04-30 14:40:53) > Чт 30 апр 2020 @ 14:06 Jan Wielemaker : > > > On 4/30/20 1:41 PM, Jonas Smedegaard wrote: > >> I think we can use the format almost as-is - just replacing the > >> leading "swipl-" with "swi-prolog-abi-". > > > > I think adding "abi" makes sense. I can replace "swipl" with the > > package name, which is "swi-prolog" for Debian. > > I'm thinking about something like as follows: > > Provides: swi-prolog-abi-$(swipl:ABI) > > where $(swipl:ABI) will be set in d/rules in override_dh_gencontrol > target, so actually it doesn't matter what is the original output of > swipl --abi_version, since we have sed and other tools to make it as > we like. What do you think, Jonas? I agree with Lev. That is what I tried to say above as well (that we can _take_ it as-is and will need to massage it only slightly), but I see now that it can just as easily be read as meaning the opposite (that we would need a slightly different format). So to (try) clarify: I think it is *perfect* usable for Debian that upstream code emits "swipl-2-67-792e14f8-de23899e" when asked for its ABI. Sorry for the confusion. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#958419: swi-prolog 8.1.29 in Debian
Чт 30 апр 2020 @ 14:06 Jan Wielemaker : > On 4/30/20 1:41 PM, Jonas Smedegaard wrote: >> I think we can use the format almost as-is - just replacing the leading >> "swipl-" with "swi-prolog-abi-". > > I think adding "abi" makes sense. I can replace "swipl" with the > package name, which is "swi-prolog" for Debian. I'm thinking about something like as follows: Provides: swi-prolog-abi-$(swipl:ABI) where $(swipl:ABI) will be set in d/rules in override_dh_gencontrol target, so actually it doesn't matter what is the original output of swipl --abi_version, since we have sed and other tools to make it as we like. What do you think, Jonas? Cheers! Lev
Bug#958419: swi-prolog 8.1.29 in Debian
On 4/30/20 1:41 PM, Jonas Smedegaard wrote: I think we can use the format almost as-is - just replacing the leading "swipl-" with "swi-prolog-abi-". I think adding "abi" makes sense. I can replace "swipl" with the package name, which is "swi-prolog" for Debian. --- Jan
Bug#959134: marked as done (astroml: (autopkgtest) needs update for new version of numpy: object of type cannot be safely interpreted as an integer)
Your message dated Thu, 30 Apr 2020 12:18:26 + with message-id and subject line Bug#959134: fixed in astroml 0.4.post1-6 has caused the Debian Bug report #959134, regarding astroml: (autopkgtest) needs update for new version of numpy: object of type cannot be safely interpreted as an integer 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.) -- 959134: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959134 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: astroml Version: 0.4.post1-5 Severity: serious X-Debbugs-CC: debian...@lists.debian.org, nu...@packages.debian.org Tags: sid bullseye User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:numpy Dear maintainer(s), With a recent upload of numpy the autopkgtest of astroml fails in testing when that autopkgtest is run with the binary packages of numpy from unstable. It passes when run with only packages from testing. In tabular form: passfail numpy from testing1:1.18.3-1 astromlfrom testing0.4.post1-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of numpy to testing [1]. Of course, numpy shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in numpy was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from numpy should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=numpy https://ci.debian.net/data/autopkgtest/testing/amd64/a/astroml/5208422/log.gz === FAILURES === ___ test_gaussian1d start = -6, stop = 10, num = 1000.0, endpoint = True, retstep = False dtype = None, axis = 0 @array_function_dispatch(_linspace_dispatcher) def linspace(start, stop, num=50, endpoint=True, retstep=False, dtype=None, axis=0): """ Return evenly spaced numbers over a specified interval. Returns `num` evenly spaced samples, calculated over the interval [`start`, `stop`]. The endpoint of the interval can optionally be excluded. .. versionchanged:: 1.16.0 Non-scalar `start` and `stop` are now supported. Parameters -- start : array_like The starting value of the sequence. stop : array_like The end value of the sequence, unless `endpoint` is set to False. In that case, the sequence consists of all but the last of ``num + 1`` evenly spaced samples, so that `stop` is excluded. Note that the step size changes when `endpoint` is False. num : int, optional Number of samples to generate. Default is 50. Must be non-negative. endpoint : bool, optional If True, `stop` is the last sample. Otherwise, it is not included. Default is True. retstep : bool, optional If True, return (`samples`, `step`), where `step` is the spacing between samples. dtype : dtype, optional The type of the output array. If `dtype` is not given, infer the data type from the other input arguments. .. versionadded:: 1.9.0 axis : int, optional The axis in the result to store the samples. Relevant only if start or stop are array-like. By default (0), the samples will be along a new axis inserted at the beginning. Use -1 to get an axis at the end. .. versionadded:: 1.16.0 Returns --- samples : ndarray There are `num` equally spaced samples in the closed interval ``[start, stop]`` or the half-open interval ``[start, stop)`` (depending on whether `endpoint` is True or False). step : float, optional Only returned if `retstep` is True
Processed: bug 959064 is forwarded to https://gitlab.kitware.com/cmake/cmake/-/issues/20652
Processing commands for cont...@bugs.debian.org: > forwarded 959064 https://gitlab.kitware.com/cmake/cmake/-/issues/20652 Bug #959064 [cmake] cmake breaks on -isystem Set Bug forwarded-to-address to 'https://gitlab.kitware.com/cmake/cmake/-/issues/20652'. > thanks Stopping processing here. Please contact me if you need assistance. -- 959064: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959064 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#959064: ignition-transport FTBFS in testing.
On 4/29/2020 10:40 PM, peter green wrote: The behavior of pkg-config has changed This lets though a -isystem parameter with a space which was previously suppressed And the space in said parameter breaks cmake. I think cmake should handle -isystem¹ and as this is reproducible without ignition-transport, I'm reassigning this to cmake. This certainly seems like the long term solution. This has been reported to CMake upstream: * PkgConfig chokes with `-isystem` with pkg-config 0.29.2 https://gitlab.kitware.com/cmake/cmake/-/issues/20652 -Brad
Processed: 936251 is fixed-upstream
Processing commands for cont...@bugs.debian.org: > tags 936251 + fixed-upstream Bug #936251 [src:bup] bup: Python2 removal in sid/bullseye Added tag(s) fixed-upstream. > End of message, stopping processing here. Please contact me if you need assistance. -- 936251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936251 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#958419: swi-prolog 8.1.29 in Debian
Чт 30 апр 2020 @ 12:42 Jonas Smedegaard : > Quoting Jan Wielemaker (2020-04-30 11:40:32) >> On 4/28/20 5:26 PM, Jonas Smedegaard wrote: >> > Quoting Jan Wielemaker (2020-04-28 16:56:30) >> >> >> That is worth a try. I guess that implies that generating >> >> SWI-Prolog (as package) also generates this hash. What kind of >> >> support would be needed from SWI-Prolog to make this work? Some >> >> script/command to create this hash for a particular system? >> > >> > Thanks for your interest in this challenge :-) >> > >> > Yes, if ABI is computed during build then what would be helpful is >> > to extend that to expose the computed ABI as a single string. Maybe >> > add it as an additional note in output of "swipl --version"? >> > >> > Or if possible to (re)compute at runtime then just document that, >> > for us distribution maintainers to integrate into our packaging >> > routines. >> >> I think I cover this nicely now: >> >> janw (linux; master) 68_> swipl --abi_version >> swipl-2-67-792e14f8-de23899e >> >> There is a section in the docs explaining the various binary ABIs and >> what aspects rely on them. There is a new function PL_version() in >> the C api that can be used to query the versions individually. >> The above says: >> >>- Backward compatibility version of the foreign interface is 2 >>- Saved state file format can be loaded when not older than 67 >>- 792e14f8 is a fingerprint for the C-defined foreign predicate >> signatures. >>- de23899e is a fingerprint of the VM instructions and their >> signatures. >> >> Does this adequately solve your problems? Do you see other >> requirements? >> >> Can you test on this, or would you rather wait for an official >> 8.1.30? I can create that now if that is useful to speedup >> stabilizing stuff to get at 8.2.0. > > That sounds really great. Thanks! > > I _think_ above described interfaces and documentation is enough for > implementing the most elegant packaging that I can imagine. > > @Lev, would you be willing to make a development snapshot (e.g. targeted > Debian experimental) then I am fine playing with that for refining an > elegant packaging mechanism. Or if you would prefer only releasing > official code then please say so. Or say if you are too busy to playing > with this now - there is no hurry from my side :-) I would prefer next release, 8.1.30, but since I will have time for it only next week (or maybe on coming Sunday) there's no hurry for Jan too (I mean to tag 8.1.30). Cheers! Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Quoting Lev Lamberov (2020-04-30 12:16:31) > Чт 30 апр 2020 @ 11:40 Jan Wielemaker : > > On 4/28/20 5:26 PM, Jonas Smedegaard wrote: > >> Quoting Jan Wielemaker (2020-04-28 16:56:30) > > > >>> That is worth a try. I guess that implies that generating > >>> SWI-Prolog (as package) also generates this hash. What kind of > >>> support would be needed from SWI-Prolog to make this work? Some > >>> script/command to create this hash for a particular system? > >> > >> Thanks for your interest in this challenge :-) > >> > >> Yes, if ABI is computed during build then what would be helpful is > >> to extend that to expose the computed ABI as a single string. > >> Maybe add it as an additional note in output of "swipl --version"? > >> > >> Or if possible to (re)compute at runtime then just document that, > >> for us distribution maintainers to integrate into our packaging > >> routines. > > > > I think I cover this nicely now: > > > > janw (linux; master) 68_> swipl --abi_version > > swipl-2-67-792e14f8-de23899e > > > > There is a section in the docs explaining the various binary ABIs > > and what aspects rely on them. There is a new function PL_version() > > in the C api that can be used to query the versions individually. > > The above says: > > > >- Backward compatibility version of the foreign interface is 2 > >- Saved state file format can be loaded when not older than 67 > >- 792e14f8 is a fingerprint for the C-defined foreign predicate > > signatures. > >- de23899e is a fingerprint of the VM instructions and their > > signatures. > > That's nice. Thanks for your work! > > Jonas, what do you think about the format? I looked into your examples > (uwsgi-plugin-php and asterisk-espeak), these packages use > alphanumeric strings as hashes; and IIRC haskell packages also use > alphanumeric hashes (but significantly shorter). Of cource we can drop > dashes and 'swipl' from the output of swipl --abi_version during > build. Or it's better to have alphanumeric string as output of swipl > --abi_version? I think we can use the format almost as-is - just replacing the leading "swipl-" with "swi-prolog-abi-". Maybe sensible to provide not opnly the full ABI but also each of the 4 more specific ABIs as separate virtual packages, but let's postpone that for a brighter future with lots of consuming packages each of them needing only some of those specific ABI parts. :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#959176: gammu-smsd: cannot start (wrong path in systemd service file)
Package: gammu-smsd
Version: 1.41.0-1
Severity: grave
Tags: patch
Dear maintainer,
The current version (1.41.0-1) of gammu-smsd cannot start the service
because the systemd service file installed in the package uses cmake
substitutions, so instead of "/usr/bin", the service file has
"${CMAKE_INSTALL_FULL_BINDIR}".
This variable is supposed to be substituted during package build, but
currently it's not, because the configure script does not find systemd
and thus, does not install the modified file; also, dh-install is
instructed to take the unmodified file from sources.
The correct way to fix this is to make systemd detectable by the
configure script, and use the modified file installed by the build
system instead of the unmodified file from sources.
Here is a patch that does this: it adds systemd to the build
dependencies so that the configure script can detect it, and instructs
dh-install to use the file installed by the build system instead of the
one from sources.
Regards,
--
Raphaël Halimi
From 7073610f61db4309df5102536320a52a72f2c948 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Halimi?=
Date: Thu, 30 Apr 2020 11:20:21 +0200
Subject: [PATCH] Fix systemd service file
---
debian/control| 3 ++-
debian/gammu-smsd.install | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/debian/control b/debian/control
index 24a16f8..ac2fab8 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,8 @@ Build-Depends: debhelper (>= 9.20160709),
libdbi-dev,
libbluetooth-dev [linux-any],
libgudev-1.0-dev [linux-any],
- libglib2.0-dev
+ libglib2.0-dev,
+ systemd
Standards-Version: 4.5.0
Vcs-Browser: https://salsa.debian.org/debian/gammu
Vcs-Git: https://salsa.debian.org/debian/gammu.git
diff --git a/debian/gammu-smsd.install b/debian/gammu-smsd.install
index 4abdaeb..1dd92a7 100644
--- a/debian/gammu-smsd.install
+++ b/debian/gammu-smsd.install
@@ -5,4 +5,4 @@ usr/share/man/man1/gammu-smsd*
usr/share/man/man7/gammu-smsd*
usr/share/man/man5/gammu-smsd*
debian/gammu-smsdrc /etc/
-contrib/init/gammu-smsd.service lib/systemd/system/
+lib/systemd/system/gammu-smsd.service
--
2.26.2
signature.asc
Description: OpenPGP digital signature
Bug#958446: nvidia-legacy-340xx-driver: Fails to build with kernel 5.6
On 30/04/2020 12.09, jim_p wrote: > And then the reference to #956458, which is for nvidia legacy 390xx. > So I would like to ask if the bug I mentioned here is indeed fixed in the -5 > revision of the package. I can't test it right now, but I probably will > tomorrow or on Saturday. I backported NVIDIA's changes from 440.82 to 418.126.02 (tesla-418), then to 390.132 (legacy-390xx) then to 340.108 (copying the wrong bug number). There were always some parts being patched not yet existing in the older releases so the patches got smaller on the way. For 340.108 it was more or less a complete redo, since nvidia significantly restructured the driver source after that series. There were also some ancient bits no longer existing in newer releases that needed to be patched additionally for 5.6. So yes, it is fixed for the 340 series, too. But as always, only compile-tested. Andreas
Bug#958419: swi-prolog 8.1.29 in Debian
Quoting Jan Wielemaker (2020-04-30 11:40:32) > On 4/28/20 5:26 PM, Jonas Smedegaard wrote: > > Quoting Jan Wielemaker (2020-04-28 16:56:30) > > >> That is worth a try. I guess that implies that generating > >> SWI-Prolog (as package) also generates this hash. What kind of > >> support would be needed from SWI-Prolog to make this work? Some > >> script/command to create this hash for a particular system? > > > > Thanks for your interest in this challenge :-) > > > > Yes, if ABI is computed during build then what would be helpful is > > to extend that to expose the computed ABI as a single string. Maybe > > add it as an additional note in output of "swipl --version"? > > > > Or if possible to (re)compute at runtime then just document that, > > for us distribution maintainers to integrate into our packaging > > routines. > > I think I cover this nicely now: > > janw (linux; master) 68_> swipl --abi_version > swipl-2-67-792e14f8-de23899e > > There is a section in the docs explaining the various binary ABIs and > what aspects rely on them. There is a new function PL_version() in > the C api that can be used to query the versions individually. > The above says: > >- Backward compatibility version of the foreign interface is 2 >- Saved state file format can be loaded when not older than 67 >- 792e14f8 is a fingerprint for the C-defined foreign predicate > signatures. >- de23899e is a fingerprint of the VM instructions and their > signatures. > > Does this adequately solve your problems? Do you see other > requirements? > > Can you test on this, or would you rather wait for an official > 8.1.30? I can create that now if that is useful to speedup > stabilizing stuff to get at 8.2.0. That sounds really great. Thanks! I _think_ above described interfaces and documentation is enough for implementing the most elegant packaging that I can imagine. @Lev, would you be willing to make a development snapshot (e.g. targeted Debian experimental) then I am fine playing with that for refining an elegant packaging mechanism. Or if you would prefer only releasing official code then please say so. Or say if you are too busy to playing with this now - there is no hurry from my side :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#954554: python-asynctest: FTBFS: tests failed
Quoting Andrej Shadura (2020-04-30 10:36:45) > Control: tag -1 patch > > On Tue, 31 Mar 2020 11:39:34 +0200 Jonas Smedegaard wrote: > > Control: https://github.com/Martiusweb/asynctest/issues/132 > > The upstream issue has a patch fixing the issue that still has not been > applied upstream, from my understanding of the code it seems sane enough > to be applied downstream in Debian. > > https://github.com/nekokatt/asynctest/commit/50225b83c0c5803b06584b173a5df837361cad3b.patch Seems the patch was proposed you and upstream dislikes it, instead wanting consumers to abandone this library. I am not happy carrying such patch, and would prefer looking into ways for reverse dependencies to avoid this library as recommended by its author. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#958419: swi-prolog 8.1.29 in Debian
Hi, Чт 30 апр 2020 @ 11:40 Jan Wielemaker : > Hi Jonas, > > On 4/28/20 5:26 PM, Jonas Smedegaard wrote: >> Quoting Jan Wielemaker (2020-04-28 16:56:30) > >>> That is worth a try. I guess that implies that generating SWI-Prolog >>> (as package) also generates this hash. What kind of support would be >>> needed from SWI-Prolog to make this work? Some script/command to >>> create this hash for a particular system? >> >> Thanks for your interest in this challenge :-) >> >> Yes, if ABI is computed during build then what would be helpful is to >> extend that to expose the computed ABI as a single string. Maybe add it >> as an additional note in output of "swipl --version"? >> >> Or if possible to (re)compute at runtime then just document that, for us >> distribution maintainers to integrate into our packaging routines. > > I think I cover this nicely now: > > janw (linux; master) 68_> swipl --abi_version > swipl-2-67-792e14f8-de23899e > > There is a section in the docs explaining the various binary ABIs > and what aspects rely on them. There is a new function PL_version() > in the C api that can be used to query the versions individually. > The above says: > >- Backward compatibility version of the foreign interface is 2 >- Saved state file format can be loaded when not older than 67 >- 792e14f8 is a fingerprint for the C-defined foreign predicate > signatures. >- de23899e is a fingerprint of the VM instructions and their > signatures. That's nice. Thanks for your work! Jonas, what do you think about the format? I looked into your examples (uwsgi-plugin-php and asterisk-espeak), these packages use alphanumeric strings as hashes; and IIRC haskell packages also use alphanumeric hashes (but significantly shorter). Of cource we can drop dashes and 'swipl' from the output of swipl --abi_version during build. Or it's better to have alphanumeric string as output of swipl --abi_version? Jan, is this hash computed only for Core_system cmake component or other components are involved too? Please, could you take a look into #959027. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959027 Jan, in case you'd like to contribute into discussion of #959027, please let's keep it separate from this (#958419) bug report. In this case please CC 958...@bugs.debian.org. Cheers! Lev
Bug#958446: nvidia-legacy-340xx-driver: Fails to build with kernel 5.6
Package: nvidia-legacy-340xx-driver Version: 340.108-4 Followup-For: Bug #958446 Dear Maintainer, I just got the email that the bug was closed and I got really happy! Then I checked the report here and I noticed this bit Closed the wrong bug in the upload ... And then the reference to #956458, which is for nvidia legacy 390xx. So I would like to ask if the bug I mentioned here is indeed fixed in the -5 revision of the package. I can't test it right now, but I probably will tomorrow or on Saturday. Thank you for your work! -- Package-specific info: uname -a: Linux mitsos 5.5.0-2-amd64 #1 SMP Debian 5.5.17-1 (2020-04-15) x86_64 GNU/Linux /proc/version: Linux version 5.5.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-10)) #1 SMP Debian 5.5.17-1 (2020-04-15) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 9.3.0 (Debian 9.3.0-10) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.309444] Console: colour VGA+ 80x25 [0.747081] pci :01:00.0: vgaarb: setting as boot VGA device [0.747081] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.747081] pci :01:00.0: vgaarb: bridge control possible [0.747081] vgaarb: loaded [0.931724] Linux agpgart interface v0.103 [3.425928] nvidia: loading out-of-tree module taints kernel. [3.425940] nvidia: module license 'NVIDIA' taints kernel. [3.469604] nvidia: module verification failed: signature and/or required key missing - tainting kernel [3.494439] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [3.496909] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0 [3.496925] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 [4.039305] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [5.260414] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input22 [5.263589] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input23 [5.264708] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input24 [5.264796] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input25 [8.867542] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs Device node permissions: crw-rw+ 1 root video 226, 0 Apr 30 12:43 /dev/dri/card0 crw-rw-rw- 1 root root 195, 0 Apr 30 12:44 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Apr 30 12:44 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Apr 30 12:43 pci-:01:00.0-card -> ../card0 video:*:44:jim OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jan 5 09:29 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 44 Jan 5 09:29 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 25 Jan 5 09:29 /etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jan 5 09:29 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jan 5 09:29 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 39 Jan 5 09:29 /etc/alternatives/glx--nvidia-drm-outputclass.conf -> /etc/nvidia/nvidia-drm-outputclass.conf lrwxrwxrwx 1 root root 28 Jan 5 09:29 /etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf lrwxrwxrwx 1 root root 32 Jan 5 09:29 /etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf lrwxrwxrwx 1 root root
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.
Bug#958419: swi-prolog 8.1.29 in Debian
Hi Jonas, On 4/28/20 5:26 PM, Jonas Smedegaard wrote: Quoting Jan Wielemaker (2020-04-28 16:56:30) That is worth a try. I guess that implies that generating SWI-Prolog (as package) also generates this hash. What kind of support would be needed from SWI-Prolog to make this work? Some script/command to create this hash for a particular system? Thanks for your interest in this challenge :-) Yes, if ABI is computed during build then what would be helpful is to extend that to expose the computed ABI as a single string. Maybe add it as an additional note in output of "swipl --version"? Or if possible to (re)compute at runtime then just document that, for us distribution maintainers to integrate into our packaging routines. I think I cover this nicely now: janw (linux; master) 68_> swipl --abi_version swipl-2-67-792e14f8-de23899e There is a section in the docs explaining the various binary ABIs and what aspects rely on them. There is a new function PL_version() in the C api that can be used to query the versions individually. The above says: - Backward compatibility version of the foreign interface is 2 - Saved state file format can be loaded when not older than 67 - 792e14f8 is a fingerprint for the C-defined foreign predicate signatures. - de23899e is a fingerprint of the VM instructions and their signatures. Does this adequately solve your problems? Do you see other requirements? Can you test on this, or would you rather wait for an official 8.1.30? I can create that now if that is useful to speedup stabilizing stuff to get at 8.2.0. Thanks --- Jan
Processed: unarchiving 759410, fixed 759410 in 0.12-2+deb9u1
Processing commands for cont...@bugs.debian.org:
> unarchive 759410
Bug #759410 {Done: Francois Marier } [safe-rm] Should not
install /usr/bin/rm conflicting with /bin/rm (blocks /bin -> /usr/bin)
Unarchived Bug 759410
> fixed 759410 0.12-2+deb9u1
Bug #759410 {Done: Francois Marier } [safe-rm] Should not
install /usr/bin/rm conflicting with /bin/rm (blocks /bin -> /usr/bin)
Marked as fixed in versions safe-rm/0.12-2+deb9u1.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
759410: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759410
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#958446: marked as done (nvidia-legacy-340xx-driver: Fails to build with kernel 5.6)
Your message dated Thu, 30 Apr 2020 11:38:03 +0200 with message-id <5a8ca749-5e29-4255-d7c7-d7f9a7f7e...@debian.org> and subject line Fwd: nvidia-graphics-drivers-legacy-340xx_340.108-5_source.changes ACCEPTED into unstable has caused the Debian Bug report #958446, regarding nvidia-legacy-340xx-driver: Fails to build with kernel 5.6 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.) -- 958446: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958446 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: nvidia-legacy-340xx-driver Version: 340.108-4 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, As with my previous bug reports, nvidia legacy 340 fails to build again. Here is the full log https://pastebin.com/i5wR0s5V Here is the patch, again from aur https://aur.archlinux.org/cgit/aur.git/plain/05-unfuck-for- kernel-5.6.x.patch?h=nvidia-340xx Unlike last time with 5.5, it seems that it patches a number of files and I do not know how to do it myself, so I can't test it. -- Package-specific info: uname -a: Linux mitsos 5.5.0-1-amd64 #1 SMP Debian 5.5.13-2 (2020-03-30) x86_64 GNU/Linux /proc/version: Linux version 5.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 9.3.0 (Debian 9.3.0-10) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.319340] Console: colour VGA+ 80x25 [0.750070] pci :01:00.0: vgaarb: setting as boot VGA device [0.750070] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.750070] pci :01:00.0: vgaarb: bridge control possible [0.750070] vgaarb: loaded [0.934312] Linux agpgart interface v0.103 [3.385956] nvidia: loading out-of-tree module taints kernel. [3.385967] nvidia: module license 'NVIDIA' taints kernel. [3.412258] nvidia: module verification failed: signature and/or required key missing - tainting kernel [3.423284] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [3.440267] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0 [3.440279] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 [3.922930] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [5.136035] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input17 [5.136119] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input18 [5.136192] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input19 [5.136267] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input25 [7.384689] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs Device node permissions: crw-rw+ 1 root video 226, 0 Apr 22 10:16 /dev/dri/card0 crw-rw-rw- 1 root root 195, 0 Apr 22 10:16 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Apr 22 10:16 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Apr 22 10:16 pci-:01:00.0-card -> ../card0 video:*:44:jim OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jan 5 09:29 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 44 Jan 5 09:29 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 Jan 5 09:29
Processed: Re: Bug#954554: python-asynctest: FTBFS: tests failed
Processing control commands: > tag -1 patch Bug #954554 [src:python-asynctest] python-asynctest: incompatible with Python 3.8 Added tag(s) patch. -- 954554: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954554 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: closing 958571
Processing commands for cont...@bugs.debian.org: > close 958571 Bug #958571 [src:hypercorn] hypercorn build-depends on package that is not in testing. Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 958571: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958571 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#954554: python-asynctest: FTBFS: tests failed
Control: tag -1 patch
On Tue, 31 Mar 2020 11:39:34 +0200 Jonas Smedegaard wrote:
Control: https://github.com/Martiusweb/asynctest/issues/132
The upstream issue has a patch fixing the issue that still has not been
applied upstream, from my understanding of the code it seems sane enough
to be applied downstream in Debian.
https://github.com/nekokatt/asynctest/commit/50225b83c0c5803b06584b173a5df837361cad3b.patch
--
Cheers,
Andrej
>From 50225b83c0c5803b06584b173a5df837361cad3b Mon Sep 17 00:00:00 2001
From: "Nekoka.tt"
Date: Sun, 14 Jul 2019 13:36:53 +0100
Subject: [PATCH] Addresses #132, addresses #126: coroutine deprecation
warnings on py38 and newer.
---
asynctest/case.py| 39 +--
asynctest/helpers.py | 5 ++--
asynctest/mock.py| 55 +---
3 files changed, 49 insertions(+), 50 deletions(-)
diff --git a/asynctest/case.py b/asynctest/case.py
index ac10ad8..275632d 100644
--- a/asynctest/case.py
+++ b/asynctest/case.py
@@ -353,8 +353,7 @@ def _run_test_method(self, method):
if asyncio.iscoroutine(result):
self.loop.run_until_complete(result)
-@asyncio.coroutine
-def doCleanups(self):
+async def doCleanups(self):
"""
Execute all cleanup functions. Normally called for you after tearDown.
"""
@@ -363,7 +362,7 @@ def doCleanups(self):
function, args, kwargs = self._cleanups.pop()
with outcome.testPartExecutor(self):
if asyncio.iscoroutinefunction(function):
-yield from function(*args, **kwargs)
+await function(*args, **kwargs)
else:
function(*args, **kwargs)
@@ -377,8 +376,7 @@ def addCleanup(self, function, *args, **kwargs):
"""
return super().addCleanup(function, *args, **kwargs)
-@asyncio.coroutine
-def assertAsyncRaises(self, exception, awaitable):
+async def assertAsyncRaises(self, exception, awaitable):
"""
Test that an exception of type ``exception`` is raised when an
exception is raised when awaiting ``awaitable``, a future or coroutine.
@@ -386,10 +384,9 @@ def assertAsyncRaises(self, exception, awaitable):
:see: :meth:`unittest.TestCase.assertRaises()`
"""
with self.assertRaises(exception):
-return (yield from awaitable)
+return await awaitable
-@asyncio.coroutine
-def assertAsyncRaisesRegex(self, exception, regex, awaitable):
+async def assertAsyncRaisesRegex(self, exception, regex, awaitable):
"""
Like :meth:`assertAsyncRaises()` but also tests that ``regex`` matches
on the string representation of the raised exception.
@@ -397,10 +394,9 @@ def assertAsyncRaisesRegex(self, exception, regex, awaitable):
:see: :meth:`unittest.TestCase.assertRaisesRegex()`
"""
with self.assertRaisesRegex(exception, regex):
-return (yield from awaitable)
+return await awaitable
-@asyncio.coroutine
-def assertAsyncWarns(self, warning, awaitable):
+async def assertAsyncWarns(self, warning, awaitable):
"""
Test that a warning is triggered when awaiting ``awaitable``, a future
or a coroutine.
@@ -408,10 +404,9 @@ def assertAsyncWarns(self, warning, awaitable):
:see: :meth:`unittest.TestCase.assertWarns()`
"""
with self.assertWarns(warning):
-return (yield from awaitable)
+return await awaitable
-@asyncio.coroutine
-def assertAsyncWarnsRegex(self, warning, regex, awaitable):
+async def assertAsyncWarnsRegex(self, warning, regex, awaitable):
"""
Like :meth:`assertAsyncWarns()` but also tests that ``regex`` matches
on the message of the triggered warning.
@@ -419,7 +414,7 @@ def assertAsyncWarnsRegex(self, warning, regex, awaitable):
:see: :meth:`unittest.TestCase.assertWarnsRegex()`
"""
with self.assertWarnsRegex(warning, regex):
-return (yield from awaitable)
+return await awaitable
class FunctionTestCase(TestCase, unittest.FunctionTestCase):
@@ -441,8 +436,7 @@ def _init_loop(self):
self.loop.time = functools.wraps(self.loop.time)(lambda: self._time)
self._time = 0
-@asyncio.coroutine
-def advance(self, seconds):
+async def advance(self, seconds):
"""
Fast forward time by a number of ``seconds``.
@@ -463,7 +457,7 @@ def advance(self, seconds):
raise ValueError(
'Cannot go back in time ({} seconds)'.format(seconds))
-yield from self._drain_loop()
+await self._drain_loop()
target_time = self._time + seconds
while True:
@@ -472,10 +466,10 @@ def advance(self, seconds):
break
self._time = next_time
-yield from
Bug#958571: hypercorn build-depends on package that is not in testing.
notfound 958571 0.9.4-1 thanks On Thu, 23 Apr 2020 21:09:46 +0100 peter green wrote: hypercorn build-depends on python3-uvloop which is not available in testing due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950165 . Either uvloop needs to be fixed, hypercorn needs to be modified to not build-depend on uvloop or hypercorn needs to be removed from testing too. It’s not a bug in hypercorn, it doesn’t need to be filed here. The package will be removed from testing at some point anyway. -- Cheers, Andrej
Processed: Re: hypercorn build-depends on package that is not in testing.
Processing commands for cont...@bugs.debian.org: > notfound 958571 0.9.4-1 Bug #958571 [src:hypercorn] hypercorn build-depends on package that is not in testing. No longer marked as found in versions hypercorn/0.9.4-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 958571: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958571 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Matthew, On Wed, Apr 29, 2020 at 05:51:26PM -0700, Matthew Fernandez wrote: > > Any more help from debian-mipsel is really appreciated. > > Hm yes, “--disable-libsanitizer” is rather ominous. I guess the mipsel GCC > package has been built without ASan support. Surprising that it fails so > messily (the front end seems to think -fsanitize=address is an accepted > command line option), but libasan does indeed seem not available on mipsel > [0]. OK, so it seems this method to track down the issue on mips does not work. > The other option I suggested was Valgrind, but if you can’t run apt-file you > probably can’t install Valgrind either. Well, I guess apt-get is permitted for sudo but not apt-file. So I can probably install valgrind inside the chroot environment. I've never worked with valgrind. What am I supposed to do? On the other hand: Is valgrind possibly able to uncover issues also on any other architecture? > If anyone spectating has ideas, please chime in. Definitely. We obviously could need some help. Kind regards Andreas. -- http://fam-tille.de
