Bug#1070130: python3-pycurl: SSL path issues - upstream bug
On Tue, 30 Apr 2024, i...@fernandolucas.info wrote: Package: python3-pycurl Version: 7.45.3-2 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, Please consider https://github.com/pycurl/pycurl/issues/834 pycurl 7.45.3 wheel not working for https in debian/ubuntu systems I confirm that the debian package for 7.45.3 fails sometimes to handle SSL connections, meanwhile 7.45.2 works properly always. Mabye it can be manually patched, or skip version 7.45.3 for debian. Are you having problems with the Debian packaged version of pycurl, or with the pycurl wheel from upstream? If the you're having problems with the packaged version of pycurl, can you please explain how to reproduce the problem? Thanks, Scott
Bug#1063462: pycurl: FTBFS during tests: GnuTLS recv error (-110): The TLS connection was non-properly terminated
Control: reassign -1 src:curl 8.6.0-1 Control: affects -1 src:pycurl On Thu, 8 Feb 2024, Emanuele Rocca wrote: Source: pycurl Version: 7.45.2-7 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: sid trixie ftbfs Dear Maintainer, pycurl currently fails to build from source on amd64 and arm64 with the following error: === FAILURES === __ CertinfoTest.test_request_without_certinfo __ self = @util.min_libcurl(7, 19, 1) @util.only_ssl def test_request_without_certinfo(self): self.curl.setopt(pycurl.URL, 'https://localhost:8383/success') sio = util.BytesIO() self.curl.setopt(pycurl.WRITEFUNCTION, sio.write) # self signed certificate self.curl.setopt(pycurl.SSL_VERIFYPEER, 0) self.curl.perform() E pycurl.error: (56, 'GnuTLS recv error (-110): The TLS connection was non-properly terminated.') tests/certinfo_test.py:34: error === warnings summary === ../../../usr/lib/python3/dist-packages/bottle.py:38 /usr/lib/python3/dist-packages/bottle.py:38: DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13 import base64, cgi, email.utils, functools, hmac, itertools, mimetypes,\ -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html ===Flaky Test Report=== === short test summary info FAILED tests/certinfo_test.py::CertinfoTest::test_request_without_certinfo - ... = 1 failed, 404 passed, 19 skipped, 5 deselected, 1 warning in 15.80s == This is a regression in curl 8.6.0. It has already been fixed/reverted upstream: https://github.com/curl/curl/commit/ed09a99af57200643d5ae001e815eeab9ffe3f84 Cherry-picking that commit should fix the issue. Regards, Scott
Bug#1063321: libwxgtk3.2-1t64 has an undeclared file conflict
On Fri, 9 Feb 2024, Scott Talbert wrote: On Tue, 6 Feb 2024, Helmut Grohne wrote: Package: libwxgtk3.2-1t64 Version: 3.2.4+dfsg-3.1~exp1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libwxgtk-gl3.2-1 libwxgtk-gl3.2-1t64 libwxgtk-media3.2-1 libwxgtk-media3.2-1t64 libwxgtk-webview3.2-1 libwxgtk-webview3.2-1t64 X-Debbugs-Cc: vor...@debian.org libwxgtk3.2-1t64 has an undeclared file conflict. This may result in an unpack error from dpkg. Hello Steve, Are you planning on fixing this, or would you like me to? If the latter, how would you like the fix submitted before this is uploaded to unstable? Sending to your vor...@dodds.net as your mail server rejected the mail sent through debian.org with some sort of SPF error. Probably something the debian server is doing? Scott
Bug#1063321: libwxgtk3.2-1t64 has an undeclared file conflict
On Tue, 6 Feb 2024, Helmut Grohne wrote: Package: libwxgtk3.2-1t64 Version: 3.2.4+dfsg-3.1~exp1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libwxgtk-gl3.2-1 libwxgtk-gl3.2-1t64 libwxgtk-media3.2-1 libwxgtk-media3.2-1t64 libwxgtk-webview3.2-1 libwxgtk-webview3.2-1t64 X-Debbugs-Cc: vor...@debian.org libwxgtk3.2-1t64 has an undeclared file conflict. This may result in an unpack error from dpkg. Hello Steve, Are you planning on fixing this, or would you like me to? If the latter, how would you like the fix submitted before this is uploaded to unstable? Regards, Scott
Bug#1052866: python-plaster: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
On Sun, 28 Jan 2024, Andreas Tille wrote: Hi, I upgraded python-plaster to latest upstream - but this did not changed the test suite error. I suspect the issue is because dh-python is clobbering the *.egg-info directories in the tests directory during the 'clean' target. While this is helpful in a lot of cases, it would be nice if there was a way to opt out of this behavior. Scott
Bug#1042325: python-miio: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
On Sat, 27 Jan 2024, Andreas Tille wrote: Control: tags -1 help Hi, I upgraded python-miio in Git. Unfortunately there are some test suite errors[1] Any help would be welcome Andreas. Fixed.
Bug#1056542: marked as pending in xlsxwriter
Control: tag -1 pending Hello, Bug #1056542 in xlsxwriter reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/xlsxwriter/-/commit/d0aea1fe82c0adcf1236a17622f62c8f73f6ae1c Update to new upstream release 3.1.9 (Closes: #1053984, #1056542) (this message was generated automatically) -- Greetings https://bugs.debian.org/1056542
Bug#1058330: marked as pending in pycurl
Control: tag -1 pending Hello, Bug #1058330 in pycurl reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pycurl/-/commit/a9b7081be4e4951ffccc04e23cef98a76fcf3380 Skip one more test to fix FTBFS with curl 8.5.0 (Closes: #1058330) (this message was generated automatically) -- Greetings https://bugs.debian.org/1058330
Bug#1057309: src:haskell-pandoc binary package names conflict with src:pandoc binary packages
reassign -1 src:pandoc
affects -1 src:haskell-pandoc
On Sun, 3 Dec 2023, Hannes von Haugwitz wrote:
Source: haskell-pandoc
Version: 3.0.1-2
Severity: serious
Control: affects -1 src:pandoc
Hi,
The binary packages provided by src:haskell-pandoc conflict with the
binary packages of src:pandoc; violationg Debian Policy 3.1 ("Every
package must have a name that’s unique within the Debian archive.").
This also makes the pandoc binary package from src:pandoc uninstallable
in unstable:
# apt policy pandoc pandoc-data
pandoc:
Installed: (none)
Candidate: 2.17.1.1-3
Version table:
2.17.1.1-3 500
500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 Packages
pandoc-data:
Installed: (none)
Candidate: 3.0.1-2
Version table:
3.0.1-2 500
500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 Packages
2.17.1.1-3 500
500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 Packages
# apt install pandoc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
pandoc : Depends: pandoc-data (< 2.17.1.1-3.~) but 3.0.1-2 is to be installed
E: Unable to correct problems, you have held broken packages.
As a workaround you can specify the matching version of pandoc-data:
# apt install pandoc pandoc-data=2.17.1.1-3
Yes, this is expected (temporarily). pandoc has been refactored upstream
and has been separated into a library and a cli package.
src:haskell-pandoc will now provide the library and data packages, while
src:pandoc needs to be updated to just provide the cli package.
Regards,
Scott
Bug#1053686: pandoc: cannot fulfill the build dependencies
On Sun, 26 Nov 2023, Scott Talbert wrote: On Sat, 25 Nov 2023, Jonas Smedegaard wrote: Quoting Scott Talbert (2023-11-25 19:09:39) On Thu, 23 Nov 2023, Jonas Smedegaard wrote: Quoting Ilias Tsitsimpis (2023-11-23 21:10:36) On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote: On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote: Quoting John MacFarlane (2023-11-16 19:25:17) Removing lua support would be most unfortunate! If you need help from upstream in getting things to work, let me know. I agree: Pandoc with its core scripting language disabled is a severely crippled Pandoc. Understood, but I am not really sure how to move forward, since Pandoc doesn't fully support the latest Stackage LTS. I can help with packaging/upgrade libraries if you can provide the right set of libraries we need. I uploaded the following packages: * haskell-hslua-cli_v1.3.0-1, * haskell-hslua-module-doclayout_v1.1.0-1 * haskell-hslua-module-zip_v1.1.0-1 I believe the next step is to update pandoc to 3.0.1, so we can then package pandoc-lua-engine, pandoc-server and eventually pandoc-cli. Jonas, how can I help move this forward? Pandoc is the last blocker to finish the Haskell transition. I think this will be the best way forward: Haskell team introduces new source package haskell-pandoc. When available, I can build package pandoc depending on it. I really don't like breaking upstream project pandoc into two Debian source packages like that, but I don't have the energy at the moment to try fix dh-haskell (which I suspect will be similar work as I am doing to dh-cargo currently). I'm working on this (packaging haskell-pandoc). And it's been uploaded, headed to NEW. Jonas, haskell-pandoc has been accepted into unstable, so I think you should be able to update src:pandoc to now build from the pandoc-cli hackage package. This brings up an interesting question, though. The pandoc-cli package versioning does not follow that of the pandoc package, so it's unclear how to best handle that with the existing numbering of src:pandoc and pandoc binary package. Regards, Scott
Bug#1053686: pandoc: cannot fulfill the build dependencies
On Sat, 25 Nov 2023, Jonas Smedegaard wrote: Quoting Scott Talbert (2023-11-25 19:09:39) On Thu, 23 Nov 2023, Jonas Smedegaard wrote: Quoting Ilias Tsitsimpis (2023-11-23 21:10:36) On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote: On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote: Quoting John MacFarlane (2023-11-16 19:25:17) Removing lua support would be most unfortunate! If you need help from upstream in getting things to work, let me know. I agree: Pandoc with its core scripting language disabled is a severely crippled Pandoc. Understood, but I am not really sure how to move forward, since Pandoc doesn't fully support the latest Stackage LTS. I can help with packaging/upgrade libraries if you can provide the right set of libraries we need. I uploaded the following packages: * haskell-hslua-cli_v1.3.0-1, * haskell-hslua-module-doclayout_v1.1.0-1 * haskell-hslua-module-zip_v1.1.0-1 I believe the next step is to update pandoc to 3.0.1, so we can then package pandoc-lua-engine, pandoc-server and eventually pandoc-cli. Jonas, how can I help move this forward? Pandoc is the last blocker to finish the Haskell transition. I think this will be the best way forward: Haskell team introduces new source package haskell-pandoc. When available, I can build package pandoc depending on it. I really don't like breaking upstream project pandoc into two Debian source packages like that, but I don't have the energy at the moment to try fix dh-haskell (which I suspect will be similar work as I am doing to dh-cargo currently). I'm working on this (packaging haskell-pandoc). And it's been uploaded, headed to NEW. Regards, Scott
Bug#1053686: pandoc: cannot fulfill the build dependencies
On Thu, 23 Nov 2023, Jonas Smedegaard wrote: Quoting Ilias Tsitsimpis (2023-11-23 21:10:36) On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote: On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote: Quoting John MacFarlane (2023-11-16 19:25:17) Removing lua support would be most unfortunate! If you need help from upstream in getting things to work, let me know. I agree: Pandoc with its core scripting language disabled is a severely crippled Pandoc. Understood, but I am not really sure how to move forward, since Pandoc doesn't fully support the latest Stackage LTS. I can help with packaging/upgrade libraries if you can provide the right set of libraries we need. I uploaded the following packages: * haskell-hslua-cli_v1.3.0-1, * haskell-hslua-module-doclayout_v1.1.0-1 * haskell-hslua-module-zip_v1.1.0-1 I believe the next step is to update pandoc to 3.0.1, so we can then package pandoc-lua-engine, pandoc-server and eventually pandoc-cli. Jonas, how can I help move this forward? Pandoc is the last blocker to finish the Haskell transition. I think this will be the best way forward: Haskell team introduces new source package haskell-pandoc. When available, I can build package pandoc depending on it. I really don't like breaking upstream project pandoc into two Debian source packages like that, but I don't have the energy at the moment to try fix dh-haskell (which I suspect will be similar work as I am doing to dh-cargo currently). I'm working on this (packaging haskell-pandoc). Regards, Scott
Bug#1053686: pandoc: cannot fulfill the build dependencies
On Sun, 8 Oct 2023, Adrian Bunk wrote: Source: pandoc Version: 2.17.1.1-3 Severity: serious Tags: ftbfs builddeps:pandoc : Depends: libghc-aeson-dev (< 2.1) but 2.1.2.1-4 is to be installed Depends: libghc-doclayout-dev (< 0.4) but 0.4.0.1-1 is to be installed Depends: libghc-haddock-library-dev (< 1.11) but 1.11.0-1 is to be installed Depends: libghc-hslua-aeson-dev (< 2.2) but 2.3.0.1-1 is to be installed Depends: libghc-hslua-marshalling-dev (< 2.2) but 2.3.0-1 is to be installed Depends: libghc-jira-wiki-markup-dev (< 1.5) but 1.5.1-1 is to be installed Depends: libghc-pandoc-types-dev (< 1.23) but 1.23.1-1 is to be installed Hi Jonas, It looks like pandoc can be updated to v3.0.1 and be compatible with the dependencies that are in unstable currently (LTS 21). Can you please let us know if there are any dependencies still missing? Scott
Bug#1052812: marked as pending in python-pytest-timeout
Control: tag -1 pending Hello, Bug #1052812 in python-pytest-timeout reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-pytest-timeout/-/commit/5b439776f7bb87c4f53bad8668fe82698e91b9e5 Switch to pyproject build (Closes: #1052812) (this message was generated automatically) -- Greetings https://bugs.debian.org/1052812
Bug#1052812: python-pytest-timeout: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
On Tue, 26 Sep 2023, Lucas Nussbaum wrote: Relevant part (hopefully): debian/rules binary dh binary --buildsystem=pybuild --with python3 dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild I: pybuild base:291: python3.11 setup.py config running config dh_auto_build -O--buildsystem=pybuild I: pybuild base:291: /usr/bin/python3 setup.py build running build running build_py copying pytest_timeout.py -> /<>/.pybuild/cpython3_3.11_python-pytest-timeout/build dh_auto_test -O--buildsystem=pybuild I: pybuild base:291: cd /<>/.pybuild/cpython3_3.11_python-pytest-timeout/build; python3.11 -m pytest I think this is happening because of the change to dh-python to remove the *.egg-info files as part of 'clean'. The egg is needed for running tests so the plugin can be found. (The egg is built as part of the build process, but not until the 'install' phase.) We could try to work around this, but I think a better solution is to switch to pyproject.toml, which I think shouldn't be affected by this problem. I sent a pull request upstream. Scott
Bug#1051155: FTBFS with doxygen 1.9.8
On Sun, 3 Sep 2023, Paolo Greppi wrote: Package: wxpython-tools Version: 4.2.1+dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: paolo.gre...@libpf.com While preparing to upload doxygen 1.9.8, I did a partial rebuild of packages that build-depend on it. More info here: https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial Yes, I'm aware of this. Doxygen 1.9.8 modified the XML output quite significantly and changed several things that wxPython relied on. :( Scott
Bug#1040855: marked as pending in setuptools-scm
Control: tag -1 pending Hello, Bug #1040855 in setuptools-scm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/setuptools-scm/-/commit/c8e8906c5da25e8c497a17116c4bad33b172fb01 Fix autopkgtests with setuptools 68 (Closes: #1040855) (this message was generated automatically) -- Greetings https://bugs.debian.org/1040855
Bug#1040583: execnet: implicitly depends on python3-py
On Fri, 7 Jul 2023, Timo Röhling wrote: Source: execnet Version: 1.9.0-2 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [Scott: Apologies that I missed this earlier, and thanks for fixing apipkg so quickly] Hey Timo, I already fixed this in execnet 1.9.0-2 (this log appears to be from execnet 1.9.0-1) after you reported the problem on apipkg. Scott
Bug#1040410: marked as pending in apipkg
Control: tag -1 pending Hello, Bug #1040410 in apipkg reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/apipkg/-/commit/a27c42488e774d50e53f0946e23e5f03b18c3d32 Add missing test dependency on python3-py (Closes: #1040410) (this message was generated automatically) -- Greetings https://bugs.debian.org/1040410
Bug#1030129: Additional information
On Tue, 20 Jun 2023, Vladimir Petko wrote: Would it be possible to consider a temporary fix[1] until all relevant openjdk packages are updated? [1] https://salsa.debian.org/java-team/ca-certificates-java/-/merge_requests/8 A temporary fix would be appreciated as there at least a few packages blocked by this issue. :) Thanks, Scott
Bug#1027612: python-envisage: FTBFS: AssertionError: 0 != 3
On Tue, 10 Jan 2023, Scott Talbert wrote: On Tue, 10 Jan 2023, Andreas Tille wrote: Hi, I've updated Git to latest upstream version which does not show the reported error any more. However, there are two other issues I seem to need help for. I've worked around the initial issue[1] FileNotFoundError: [Errno 2] No such file or directory: 'python' with a patch[2] but this finally leads to a different error[3] subprocess.CalledProcessError: Command '['python3', 'setup.py', 'bdist_egg', '--dist-dir', '/tmp/tmp14hpgj33']' returned non-zero exit status 1. Any help would be welcome Andreas. [1] https://salsa.debian.org/python-team/packages/python-envisage/-/jobs/3774020 [2] https://salsa.debian.org/python-team/packages/python-envisage/-/blob/master/debian/patches/python3.patch [3] https://salsa.debian.org/python-team/packages/python-envisage/-/jobs/3774219 I'm looking into this. It appears that something is going horribly wrong with the test egg generation (which is now being done upstream automatically). Pushed a fix to salsa for that issue. It seems that some of the Debian build environment variables were interfering with the test egg generation process. Scott
Bug#1019799: Proposed MBF: wxwidgets3.2 transition
On Mon, 9 Jan 2023, gregor herrmann wrote: On Sun, 08 Jan 2023 16:56:14 -0500, Scott Talbert wrote: On Thu, 15 Sep 2022, gregor herrmann wrote: On Thu, 15 Sep 2022 15:13:24 -0400, Scott Talbert wrote: Thanks for your work so far. I'll try to take a stab at it... Great, thank you! (The preliminary patch is in git: https://salsa.debian.org/perl-team/modules/packages/libwx-perl ) I just submitted a PR [1] with a patch to move libwx-perl to wxWidgets 3.2. I tested with a few of libwx-perl's rdeps (kephra, unifont-bin, eekboek-gui [as much as I could understand it]), and I didn't notice any obvious problems. [1] https://salsa.debian.org/perl-team/modules/packages/libwx-perl/-/merge_requests/1 Thank you very much! Merged, and libalien-wxwidgets-perl and libwx-perl uploaded to unstable. Hi gregor, It seems that libalien-wxwidgets-perl is failing its autopkgtests. I looked at it, but I can't understand why it is failing. Can you take a look when you have a chance? Regards, Scott
Bug#1027612: python-envisage: FTBFS: AssertionError: 0 != 3
On Tue, 10 Jan 2023, Andreas Tille wrote: Hi, I've updated Git to latest upstream version which does not show the reported error any more. However, there are two other issues I seem to need help for. I've worked around the initial issue[1] FileNotFoundError: [Errno 2] No such file or directory: 'python' with a patch[2] but this finally leads to a different error[3] subprocess.CalledProcessError: Command '['python3', 'setup.py', 'bdist_egg', '--dist-dir', '/tmp/tmp14hpgj33']' returned non-zero exit status 1. Any help would be welcome Andreas. [1] https://salsa.debian.org/python-team/packages/python-envisage/-/jobs/3774020 [2] https://salsa.debian.org/python-team/packages/python-envisage/-/blob/master/debian/patches/python3.patch [3] https://salsa.debian.org/python-team/packages/python-envisage/-/jobs/3774219 I'm looking into this. It appears that something is going horribly wrong with the test egg generation (which is now being done upstream automatically). Scott
Bug#1019799: Proposed MBF: wxwidgets3.2 transition
On Thu, 15 Sep 2022, gregor herrmann wrote: On Thu, 15 Sep 2022 15:13:24 -0400, Scott Talbert wrote: And we are getting further, configure passes, then the actual build fails: … So, hm, yeah, I guess this needs some more fixes and some more knowledge about wxWidegts … Thanks for your work so far. I'll try to take a stab at it... Great, thank you! (The preliminary patch is in git: https://salsa.debian.org/perl-team/modules/packages/libwx-perl ) Hi, I just submitted a PR [1] with a patch to move libwx-perl to wxWidgets 3.2. I tested with a few of libwx-perl's rdeps (kephra, unifont-bin, eekboek-gui [as much as I could understand it]), and I didn't notice any obvious problems. Regards, Scott [1] https://salsa.debian.org/perl-team/modules/packages/libwx-perl/-/merge_requests/1
Bug#1027564: haskell-curl: FTBFS: from curlc.c:10:0: error:
Control: reassign -1 src:curl 7.87.0-1
Control: affects -1 src:haskell-curl
Control: forwarded -1 https://github.com/curl/curl/issues/10148
On Sun, 1 Jan 2023, Lucas Nussbaum wrote:
Source: haskell-curl
Version: 1.3.8-13
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230101 ftbfs-bookworm
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
debian/rules binary
test -x debian/rules
dh_testroot
dh_prep
dh_installdirs -A
mkdir -p "."
CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
Adding cdbs dependencies to debian/libghc-curl-doc.substvars
dh_installdirs -plibghc-curl-doc \
perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ \
-E 'make_setup_recipe'
Running ghc --make Setup.hs -o debian/hlibrary.setup
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking debian/hlibrary.setup ...
perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ \
-E 'configure_recipe'
Running find . ! -newer /tmp/lTGCgHLmiB -exec touch -d 1998-01-01 UTC {} ;
Running dh_listpackages
libghc-curl-dev
libghc-curl-prof
libghc-curl-doc
Running dh_listpackages
libghc-curl-dev
libghc-curl-prof
libghc-curl-doc
Running dpkg-buildflags --get LDFLAGS
-Wl,-z,relro
Running debian/hlibrary.setup configure --ghc -v2
--package-db=/var/lib/ghc/package.conf.d --prefix=/usr
--libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib
--builddir=dist-ghc --ghc-option=-optl-Wl,-z,relro
--haddockdir=/usr/lib/ghc-doc/haddock/curl-1.3.8/ --datasubdir=curl
--htmldir=/usr/share/doc/libghc-curl-doc/html/ --enable-library-profiling
Using Parsec parser
Configuring curl-1.3.8...
Flags chosen: new-base=True
Dependency base >=3 && <5: using base-4.15.1.0
Dependency bytestring >=0.9: using bytestring-0.10.12.1
Dependency containers: using containers-0.6.4.1
Source component graph: component lib
Configured component graph:
component curl-1.3.8-A0wPVE8VAFIAErUUBZVdib
include base-4.15.1.0
include bytestring-0.10.12.1
include containers-0.6.4.1
Linked component graph:
unit curl-1.3.8-A0wPVE8VAFIAErUUBZVdib
include base-4.15.1.0
include bytestring-0.10.12.1
include containers-0.6.4.1
Network.Curl=curl-1.3.8-A0wPVE8VAFIAErUUBZVdib:Network.Curl,Network.Curl.Code=curl-1.3.8-A0wPVE8VAFIAErUUBZVdib:Network.Curl.Code,Network.Curl.Debug=curl-1.3.8-A0wPVE8VAFIAErUUBZVdib:Network.Curl.Debug,Network.Curl.Easy=curl-1.3.8-A0wPVE8VAFIAErUUBZVdib:Network.Curl.Easy,Network.Curl.Info=curl-1.3.8-A0wPVE8VAFIAErUUBZVdib:Network.Curl.Info,Network.Curl.Opts=curl-1.3.8-A0wPVE8VAFIAErUUBZVdib:Network.Curl.Opts,Network.Curl.Post=curl-1.3.8-A0wPVE8VAFIAErUUBZVdib:Network.Curl.Post,Network.Curl.Types=curl-1.3.8-A0wPVE8VAFIAErUUBZVdib:Network.Curl.Types
Ready component graph:
definite curl-1.3.8-A0wPVE8VAFIAErUUBZVdib
depends base-4.15.1.0
depends bytestring-0.10.12.1
depends containers-0.6.4.1
Using Cabal-3.4.1.0 compiled by ghc-9.0
Using compiler: ghc-9.0.2
Using install prefix: /usr
Executables installed in: /usr/bin
Libraries installed in:
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-9.0.2/curl-1.3.8-A0wPVE8VAFIAErUUBZVdib
Dynamic Libraries installed in:
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-9.0.2
Private executables installed in: /usr/lib/x86_64-linux-ghc-9.0.2/curl-1.3.8
Data files installed in: /usr/share/curl
Documentation installed in: /usr/share/doc/x86_64-linux-ghc-9.0.2/curl-1.3.8
Configuration files installed in: /usr/etc
No alex found
Using ar found on system at: /usr/bin/x86_64-linux-gnu-ar
No c2hs found
No cpphs found
No doctest found
Using gcc version 12 found on system at: /usr/bin/x86_64-linux-gnu-gcc
Using ghc version 9.0.2 found on system at: /usr/bin/ghc
Using ghc-pkg version 9.0.2 found on system at: /usr/bin/ghc-pkg
No ghcjs found
No ghcjs-pkg found
No greencard found
Using haddock version 2.25.1 found on system at: /usr/bin/haddock
No happy found
Using haskell-suite found on system at: haskell-suite-dummy-location
Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location
No hmake found
Using hpc version 0.68 found on system at: /usr/bin/hpc
Using hsc2hs version 0.68.7 found on system at: /usr/bin/hsc2hs
Using hscolour version 1.24 found on system at: /usr/bin/HsColour
No jhc found
Using ld found on system at: /usr/bin/x86_64-linux-gnu-ld.gold
No pkg-config found
Using runghc version 9.0.2 found on system at: /usr/bin/runghc
Using strip version 2.39 found on system at: /usr/bin/strip
Using tar found on system at: /bin/tar
No uhc found
touch configure-ghc-stamp
perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ \
-E 'build_recipe'
Running dh_listpackages
libghc-curl-dev
libghc-curl-prof
libghc-curl-doc
Preprocessing library for curl-1.3.8..
Bug#1019828: marked as pending in megaglest
Control: tag -1 pending Hello, Bug #1019828 in megaglest reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/megaglest/-/commit/b8d9bd377b86afa78b06d13047d396eeb58dda5b Transition to wxWidgets 3.2 (Closes: #1019828) (this message was generated automatically) -- Greetings https://bugs.debian.org/1019828
Bug#1026605: python-avro: FTBFS: AssertionError: 'reader type: null not compatible with writer type: int' not found in {'reader type: SchemaType.NULL not compatible with writer type: SchemaType.INT'}
On Thu, 29 Dec 2022, Scott Kitterman wrote:
On Thursday, December 29, 2022 4:13:20 PM EST Andreas Tille wrote:
Control: tags -1 help
Hi,
I wonder whether someone might suggest a fix for
==
FAIL: test_schema_compatibility_type_mismatch
(avro.test.test_compatibility.TestCompatibility.test_schema_compatibility_t
ype_mismatch)
--
Traceback (most recent call last):
File
"/build/python-avro-1.11.1+dfsg/.pybuild/cpython3_3.11_avro/build/avro/test
/test_compatibility.py", line 1039, in
test_schema_compatibility_type_mismatch self.assertIn(message,
result.messages)
AssertionError: 'reader type: null not compatible with writer type: int' not
found in {'reader type: SchemaType.NULL not compatible with writer type:
SchemaType.INT'}
--
Ran 421 tests in 8.358s
FAILED (failures=1, skipped=3)
Otherwise I will probably exclude Python3.11 from the build to fix this bug.
That's not an actual solution. If you close the bug on this basis it will
hide the issue and make it appear we are more ready to move to Python 3.11 as
the default (and probably only) Python version for Bookworm.
I didn't look at the actual code. Typically when something comes up Null is
means that something was not found. I would look at the code where SchemaType
is determined to see how it might come up with no SchemaType.
It looks like this has already been fixed upstream (although with a
non-obvious commit message):
https://github.com/apache/avro/commit/432f073c3cfb8ac7edb2793b797ab855c5a978dd
I just uploaded a fix.
Scott T.
Bug#1026605: marked as pending in python-avro
Control: tag -1 pending Hello, Bug #1026605 in python-avro reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-avro/-/commit/febc8ecea3d0c6ff366d5fe1a4d1f0dbc90bc2b9 Cherry-pick upstream fix for Python 3.11 tests (Closes: #1026605) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026605
Bug#1023365: prusa-slicer: Wrong wxWidgets Version linked during debian Build resulting in instant SIGSEGV on launch (due to lacking wxWidgets 3.2 support)
On Tue, 27 Dec 2022, Chow Loong Jin wrote: On Wed, Dec 21, 2022 at 06:34:40PM +1300, Olly Betts wrote: On Wed, Dec 21, 2022 at 11:21:03AM +0800, Chow Loong Jin wrote: I've fixed the segfault by applying the patch from [1], but there's one issue remaining -- PrusaSlicer fails to initialize GLEW due to [2], resulting in the plater screen not showing up, same as this SuperSlicer issue[3]. I've also attempted to roll PrusaSlicer back to wxwidgets3.0 Please don't do that. We're really close to eliminating wxwidgets3.0 now, and we're not planning to include it in the bookworm release. We're going to switch to --disable-glcanvasegl in wxwidgets3.2 which should solve the incompatibilities with GLEW which seem to be the problem here. However that's an ABI breaking change affecting any packages using wxwidgets3.2's OpenGL APIs so it needs coordinating with the release team - Scott is currently working on that. Alright, I'll leave the slic3r-prusa as-is then. I'm guessing that a binNMU will take care of things when we get there. wxwidgets3.2 has been rebuilt in unstable with EGL support disabled. The release team skipped the binNMU of slic3r-prusa due to bug #1025827. If you upload the (already merged) fix for that bug, that should take care of this rebuild for slic3r-prusa too. Thanks, Scott
Bug#1026021: pytest-forked: FTBFS with pytest 7.2
On Tue, 13 Dec 2022, Timo Röhling wrote: Source: pytest-forked Version: 1.4.0-1 Severity: serious Tags: ftbfs patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package FTBFS with pytest 7.2; the test summary has been augmented with a reason, which is not captured by test_xfail_behavior.py: Thanks, I did notice this but I was planning to wait on a new upstream release which should fix this (hopefully coming soon). Regards, Scott
Bug#1010973: python-tesserocr: flaky autopkgtest
On Sun, 18 Dec 2022, Malik Mlitat wrote: Hello DPT, I have updated the package python-tesserocr [1] to skip the flaky test to fix the issue below. I need a maintainer please to upload the new release version 2.5.2-2 to the Debian archive. [1] https://salsa.debian.org/python-team/packages/python-tesserocr Uploaded. But the ftp-master server is down, so it's unclear when that will be fixed (and hopefully the uploads that are occurring now will be processed?). Regards, Scott
Bug#1017415: Sponsored upload needed to fix elpa-agda2-mode #1017415
On Tue, 6 Dec 2022, Helmut Grohne wrote: Hi Scott, On Tue, Dec 06, 2022 at 11:54:49AM -0500, Scott Talbert wrote: Run "dht tag ". Push tag. :) I suppose one needs commit access to DHG_packages to do this. Given that I don't intend to maintain haskell stuff (or packages in general), I think it would be easier if you or someone else could just create the tag than grant me access. I have commit access to waaay too many repos already. It's accepted in unstable. Done. Scott
Bug#1017415: Sponsored upload needed to fix elpa-agda2-mode #1017415
On Tue, 6 Dec 2022, Helmut Grohne wrote: Hi Marcel, On Tue, Dec 06, 2022 at 05:08:10PM +0100, Marcel Fourné wrote: I just pushed a fix for #1017415 to the group repo and if somebody could upload it, the package (and therefore the whole agda system) would be installable again. I tested the agda-mode with a local clean rebuild and an agda hello world example, which worked fine. I'm including the original bug reporter to this mail, since they might be interested to see some progress here. Thanks for fixing this issue. I confirm that your fix works. I can not only install it, but also use it interatively in emacs again. Thanks. Uploaded. Do you happen to know the DHG processes for tagging this? Run "dht tag ". Push tag. :) Scott
Bug#1023020: cmark-gfm: FTBFS on s390x
On Wed, 30 Nov 2022, Keith Packard wrote: Scott Talbert writes: @Keith, do you have time to upload this patch? Unfortunately, this is blocking a large number of packages from migrating to testing. Alternatively, any objections to an NMU? Thanks for the NMU! Did you happen to create a git repo with this change? I just noticed that the salsa repo is in my private space. g...@salsa.debian.org:keithp/cmark-gfm.git No, I didn't, since I wasn't aware you were using a Vcs for packaging (no Vcs listed in d/control). I can send you a merge request with the changes, if you'd like? Regards, Scott
Bug#1023020: cmark-gfm: FTBFS on s390x
On Tue, 29 Nov 2022, Chris Hofstaedtler wrote: * Sebastian Ramacher [221129 11:21]: Source: cmark-gfm Version: 0.29.0.gfm.6-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) https://buildd.debian.org/status/fetch.php?pkg=cmark-gfm=s390x=0.29.0.gfm.6-2=1666810004=0 --- expected HTML +++ actual HTML @@ -7,15 +7,15 @@ mailto:scyt...@pokemon.com;>scyt...@pokemon.com/mailto:beedr...@pokemon.com;>beedr...@pokemon.com mailto:scyt...@pokemon.com;>mailto:scyt...@pokemon.com This is a mailto:scyt...@pokemon.com;>mailto:scyt...@pokemon.com -mailto:scyt...@pokemon.com;>mailto:scyt...@pokemon.com. +mailto:mailto:scyt...@pokemon.com;>scyt...@pokemon.com. This is caused by an out-of-bounds read on a memory buffer, which seems to be masked by stack layout on little-endian archs(?). PR for upstream is here: https://github.com/github/cmark-gfm/pull/296/files I've verified on zelenka.d.o this fixes the build failure. Thanks for the fix, Chris! I was trying to look into this myself earlier. @Keith, do you have time to upload this patch? Unfortunately, this is blocking a large number of packages from migrating to testing. Alternatively, any objections to an NMU? Thanks, Scott
Bug#1023149: pandoc: diff for NMU version 2.17.1.1-1.1
On Sat, 19 Nov 2022, Adrian Bunk wrote: Control: tags 1023149 + patch Control: tags 1023149 + pending Dear maintainer, I've prepared an NMU for pandoc (versioned as 2.17.1.1-1.1) and uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it. Can this NMU be accepted ASAP? Assuming I'm reading excuses correctly, I believe this is preventing a massive number of haskell packages from migrating to testing. Thanks, Scott
Bug#1023913: marked as pending in sip4
Control: tag -1 pending Hello, Bug #1023913 in sip4 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/sip4/-/commit/e07db942427703904c5bf891eec17f6765b69b63 Fix FTBFS with Python 3.11 (Closes: #1023913) (this message was generated automatically) -- Greetings https://bugs.debian.org/1023913
Bug#1019812: wxhexeditor: Please transition to wxwidgets3.2
On Sat, 5 Nov 2022, Paul Wise wrote: Control: tags -1 + fixed-upstream patch Control: forwarded -1 https://github.com/EUA/wxHexEditor/commit/28151fc64cb6d01a08dc80ef750d4bca96c147e7 https://github.com/EUA/wxHexEditor/commit/ebe2449fac22089825d124935a215fd1c0739403 On Wed, 14 Sep 2022 15:42:16 -0400 Scott Talbert wrote: Please transition wxhexeditor from wxwidgets3.0 to wxwidgets3.2. This causes a build failure due to WX_CLEAR_ARRAY calls not having a terminating semicolon in the version in Debian. Fixing those makes the package build and I have tested that the package works afterwards. The missing semicolons are fixed in the two upstream commits above. Yep, I had prepared a pull request independently with these fixes (didn't check upstream, oops), but it should be ready to go: https://salsa.debian.org/debian/wxhexeditor/-/merge_requests/2 Regards, Scott
Bug#1019805: 4pane: Please transition to wxwidgets3.2
On Fri, 4 Nov 2022, da...@4pane.co.uk wrote: My apologies for the delay in replying. While the fix itself was easy, I wanted to incorporate it into the forthcoming 4pane release, avoiding the hassle of an extra RFS. I've now done this and uploaded it to mentors (https://mentors.debian.net/package/4pane/ and https://mentors.debian.net/debian/pool/main/4/4pane/4pane_8.0-1.dsc). However that gives only a few days for a sponsor to appear before 4pane is autoremoved on 8/11. So if you, or someone you know, would be able to do this I'd be most grateful. Or if it's possible to delay the autoremoval... I'm happy to sponsor. That's great! Thank you. However, the first thing I notice is that the package still Build-Depends on libwxgtk3.0-gtk3-dev... Scott Argh! I'd not noticed that. Now fixed and re-uploaded. I didn't add libwxgtk3.0-gtk3-dev to Build-Conflicts, but it doesn't seem to be necessary: a test build picked the 3.2-dev even though both were present. However I can easily do so if you prefer. Uploaded. Can you please commit that Build-Depends change to your packaging repo and also tag it "debian/8.0-1"? Thanks, Scott
Bug#1019805: 4pane: Please transition to wxwidgets3.2
On November 4, 2022 6:28:50 PM EDT, da...@4pane.co.uk wrote: >>On Fri, 4 Nov 2022, da...@4pane.co.uk wrote: >> >>> My apologies for the delay in replying. While the fix itself was easy, I >>> wanted to incorporate it into the forthcoming 4pane release, avoiding the >>> hassle of an extra RFS. >>> >>> I've now done this and uploaded it to mentors >>> (https://mentors.debian.net/package/4pane/ and >>> https://mentors.debian.net/debian/pool/main/4/4pane/4pane_8.0-1.dsc). >>> However >>> that gives only a few days for a sponsor to appear before 4pane is >>> autoremoved on 8/11. So if you, or someone you know, would be able to do >>> this I'd be most grateful. Or if it's possible to delay the autoremoval... >> >>I'm happy to sponsor. > >That's great! Thank you. > >> However, the first thing I notice is that the package >>still Build-Depends on libwxgtk3.0-gtk3-dev... >>Scott > >Argh! I'd not noticed that. Now fixed and re-uploaded. > >I didn't add libwxgtk3.0-gtk3-dev to Build-Conflicts, but it doesn't seem to be >necessary: a test build picked the 3.2-dev even though both were present. >However I can easily do so if you prefer. Not necessary. When build on the Debian buildds, only a minimal environment is present, so no need to exclude other wx packages. Scott
Bug#1019805: 4pane: Please transition to wxwidgets3.2
On Fri, 4 Nov 2022, da...@4pane.co.uk wrote: My apologies for the delay in replying. While the fix itself was easy, I wanted to incorporate it into the forthcoming 4pane release, avoiding the hassle of an extra RFS. I've now done this and uploaded it to mentors (https://mentors.debian.net/package/4pane/ and https://mentors.debian.net/debian/pool/main/4/4pane/4pane_8.0-1.dsc). However that gives only a few days for a sponsor to appear before 4pane is autoremoved on 8/11. So if you, or someone you know, would be able to do this I'd be most grateful. Or if it's possible to delay the autoremoval... I'm happy to sponsor. However, the first thing I notice is that the package still Build-Depends on libwxgtk3.0-gtk3-dev... Scott
Bug#1019784: marked as pending in scorched3d
Control: tag -1 pending Hello, Bug #1019784 in scorched3d reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/scorched3d/-/commit/d997808b68bc1901ef182933177a53704d15cb01 Transition to wxWidgets 3.2 (Closes: #1019784) (this message was generated automatically) -- Greetings https://bugs.debian.org/1019784
Bug#1019792: marked as pending in springlobby
Control: tag -1 pending Hello, Bug #1019792 in springlobby reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/springlobby/-/commit/a0cad0c3f5090dcd96ffef2f09a13ea6c7ffd188 Transition to wxWidgets 3.2 (Closes: #1019792) (this message was generated automatically) -- Greetings https://bugs.debian.org/1019792
Bug#1023156: haskell-gi-gtk FTBFS on armel
On Sun, 30 Oct 2022, Adrian Bunk wrote: haskell-gi-gtk has only once ever been built successfully on armel. Unless someone has a better suggestion, my short-term Plan B would be that I request the removal of haskell-gi-gtk and reverse dependencies on armel. I think that's probably a good plan. I believe I may have reported this bug (or one similar to it) to ghc, but it didn't sound like it was something that was going to fixed quickly/easily. Scott
Bug#1019839: marked as pending in 0ad
Control: tag -1 pending Hello, Bug #1019839 in 0ad reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/0ad/-/commit/266cb899d6f4fa3d68859cbefc71c5121e0b9ea6 Transition to wxWidgets 3.2 (Closes: #1019839) (this message was generated automatically) -- Greetings https://bugs.debian.org/1019839
Bug#1019773: marked as pending in asc
Control: tag -1 pending Hello, Bug #1019773 in asc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/asc/-/commit/02824981ba3d8dc47558fb51c5fa5615e988249e Transition to wxWidgets 3.2 (Closes: #1019773) (this message was generated automatically) -- Greetings https://bugs.debian.org/1019773
Bug#1019819: qutemol: Please transition to wxwidgets3.2
On Sun, 23 Oct 2022, Graham Inggs wrote: Control: tags -1 + help Hi Scott Thanks for driving the transition to wxwidgets3.2. I've tried switching the Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev in qutemol, but the build fails with the output below. Any hints would be appreciated. Hi Graham, I sent a pull request[1] to fix the compile issue (basically, qutemol was using a long-deprecated API for wxGLCanvas that was finally removed in wx 3.2). However, after fixing that, qutemol runs into another problem, which is basically that wxWidgets 3.2, which is compiled to use OpenGL EGL, is incompatible with glew, which is compiled to use OpenGL GLX. This is documented in this bug[2] and still needs to be sorted out. Regards, Scott [1] https://salsa.debian.org/debichem-team/qutemol/-/merge_requests/2 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020640
Bug#1020010: cvc4: FTBFS: expr_template.h:0: error: undefined replacement ${getConst_instantiations}
Control: tags -1 patch On Sun, 18 Sep 2022, Lucas Nussbaum wrote: Source: cvc4 Version: 1.8-2 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20220917 ftbfs-bookworm Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): make[3]: Entering directory '/<>/obj-x86_64-linux-gnu' make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' [ 1%] Generating metakind.h cd /<>/obj-x86_64-linux-gnu/src/expr && /usr/bin/cmake -E env CMAKE_SOURCE_DIR=/<> /<>/src/expr/mkmetakind /<>/src/expr/metakind_template.h /<>/src/theory/builtin/kinds /<>/src/theory/booleans/kinds /<>/src/theory/uf/kinds /<>/src/theory/arith/kinds /<>/src/theory/bv/kinds /<>/src/theory/fp/kinds /<>/src/theory/arrays/kinds /<>/src/theory/datatypes/kinds /<>/src/theory/sep/kinds /<>/src/theory/sets/kinds /<>/src/theory/strings/kinds /<>/src/theory/quantifiers/kinds > /<>/obj-x86_64-linux-gnu/src/expr/metakind.h [ 1%] Built target gen-tokens [ 1%] Generating theory_traits.h cd /<>/obj-x86_64-linux-gnu/src/theory && /<>/src/theory/mktheorytraits /<>/src/theory/theory_traits_template.h /<>/src/theory/builtin/kinds /<>/src/theory/booleans/kinds /<>/src/theory/uf/kinds /<>/src/theory/arith/kinds /<>/src/theory/bv/kinds /<>/src/theory/fp/kinds /<>/src/theory/arrays/kinds /<>/src/theory/datatypes/kinds /<>/src/theory/sep/kinds /<>/src/theory/sets/kinds /<>/src/theory/strings/kinds /<>/src/theory/quantifiers/kinds > /<>/obj-x86_64-linux-gnu/src/theory/theory_traits.h [ 1%] Generating Debug_tags.tmp [ 1%] Built target gen-gitinfo cd /<>/obj-x86_64-linux-gnu/src/base && /<>/src/base/gentmptags.sh /<>/src/base Debug /<>/src/api/cvc4cpp.cpp\ /<>/src/api/cvc4cpp.h\ /<>/src/api/cvc4cppkind.h\ /<>/src/base/check.cpp\ /<>/src/base/check.h\ /<>/src/base/configuration.cpp\ /<>/src/base/configuration.h\ /<>/src/base/configuration_private.h\ /<>/src/base/exception.cpp\ /<>/src/base/exception.h\ /<>/src/base/listener.cpp\ /<>/src/base/listener.h\ /<>/src/base/map_util.h\ /<>/src/base/modal_exception.h\ /<>/src/base/output.cpp\ /<>/src/base/output.h\ /<>/src/bindings/java_iterator_adapter.h\ /<>/src/bindings/java_stream_adapters.h\ /<>/src/bindings/swig.h\ /<>/src/context/backtrackable.h\ /<>/src/context/cddense_ set.h\ /<>/src/context/cdhashmap.h\ /<>/src/context/cdhashmap_forward.h\ /<>/src/context/cdhashset.h\ /<>/src/context/cdhashset_forward.h\ /<>/src/context/cdinsert_hashmap.h\ /<>/src/context/cdinsert_hashmap_forward.h\ /<>/src/context/cdlist.h\ /<>/src/context/cdlist_forward.h\ /<>/src/context/cdmaybe.h\ /<>/src/context/cdo.h\ /<>/src/context/cdqueue.h\ /<>/src/context/cdtrail_queue.h\ /<>/src/context/context.cpp\ /<>/src/context/context.h\ /<>/src/context/context_mm.cpp\ /<>/src/context/context_mm.h\ /<>/src/decision/decision_attributes.h\ /<>/src/decision/decision_engine.cpp\ /<>/src/decision/decision_engine.h\ /<>/src/decision/decision_strategy.h\ /<>/src/decision/justification_heuristic.cpp\ /<>/sr c/decision/justification_heuristic.h\ /<>/src/expr/array.h\ /<>/src/expr/array_store_all.cpp\ /<>/src/expr/array_store_all.h\ /<>/src/expr/ascription_type.h\ /<>/src/expr/attribute.cpp\ /<>/src/expr/attribute.h\ /<>/src/expr/attribute_internals.h\ /<>/src/expr/attribute_unique_id.h\ /<>/src/expr/datatype.cpp\ /<>/src/expr/datatype.h\ /<>/src/expr/dtype.cpp\ /<>/src/expr/dtype.h\ /<>/src/expr/dtype_cons.cpp\ /<>/src/expr/dtype_cons.h\ /<>/src/expr/dtype_selector.cpp\ /<>/src/expr/dtype_selector.h\ /<>/src/expr/emptyset.cpp\ /<>/src/expr/emptyset.h\ /<>/src/expr/expr_iomanip.cpp\ /<>/src/expr/expr_iomanip.h\ /<>/src/expr/expr_manager_scope.h\ /<>/src/expr/expr_manager_template.cpp\ /<>/src/e xpr/expr_manager_template.h\ /<>/src/expr/expr_sequence.cpp\ /<>/src/expr/expr_sequence.h\ /<>/src/expr/expr_template.cpp\ /<>/src/expr/expr_template.h\ /<>/src/expr/kind_map.h\ /<>/src/expr/kind_template.cpp\ /<>/src/expr/kind_template.h\ /<>/src/expr/lazy_proof.cpp\ /<>/src/expr/lazy_proof.h\ /<>/src/expr/match_trie.cpp\ /<>/src/expr/match_trie.h\ /<>/src/expr/metakind_template.cpp\ /<>/src/expr/metakind_template.h\ /<>/src/expr/node.cpp\ /<>/src/expr/node.h\ /<>/src/expr/node_algorithm.cpp\ /<>/src/expr/node_algorithm.h\ /<>/src/expr/node_builder.h\ /<>/src/expr/node_manager.cpp\ /<>/src/expr/node_manager.h\ /<>/src/expr/node_manager_attributes.h\ /<>/src/expr/node_manager_listeners.cpp\ /<>/src/expr/node_manager_listeners.h\ /<>/src/expr/node_self_iterator.h\ /<>/src/expr/node_traversal.cpp\ /<>/src/expr/node_traversal.h\ /<>/src/expr/node_trie.cpp\ /<>/src/expr/node_trie.h\ /<>/src/expr/node_value.cpp\ /<>/src/expr/node_value.h\ /<>/src/expr/node_visitor.h\ /<>/src/expr/proof.cpp\ /<>/src/expr/proof.h\ /<>/src/expr/proof_checker.cpp\ /<>/src/expr/proof_checker.h\ /<>/src/expr/proof_generator.cpp\ /<>/src/expr/proof_generator.h\ /<>/src/expr/proof_node.cpp\ /<>/src/expr/proof_node.h\ /<>/src/expr/proof_node_algorithm.cpp\
Bug#1021394: src:libcereal: FTBFS on arm, ppc64le, s390x
Control: tags -1 patch On Fri, 7 Oct 2022, Scott Talbert wrote: Control: tags -1 help Control: tags -1 upstream Control: tags -1 forwarded https://github.com/USCiLab/cereal/issues/744 Merge request sent with patch: https://salsa.debian.org/med-team/libcereal/-/merge_requests/1 Regards, Scott
Bug#1021394: src:libcereal: FTBFS on arm, ppc64le, s390x
On Fri, 7 Oct 2022, Andreas Tille wrote:
Control: tags -1 help
Control: tags -1 upstream
Control: tags -1 forwarded https://github.com/USCiLab/cereal/issues/744
Am Fri, Oct 07, 2022 at 09:37:03AM -0400 schrieb Scott Talbert:
Justification: fails to build from source (but built successfully in the past)
I guess it never has built in the past but the package was formerly
Architecture: all and thus it was somehow available on the said
architectures without really working there which was left unnoticed.
It seems, though, that it *has* been built in the past, e.g., on arm64:
https://buildd.debian.org/status/logs.php?pkg=libcereal=arm64
It looks like this package was not always Architecture: all, see:
https://salsa.debian.org/med-team/libcereal/-/commit/3e3f4a3b4e9bb068a87fd6fd118df01571b88448
libcereal 1.3.2+dfsg-3 FTBFS on arm, ppc64le, s390x. This seems to be
the relevant error:
[ 22%] Building CXX object unittests/CMakeFiles/test_map.dir/map.cpp.o
cd /<>/obj-aarch64-linux-gnu/unittests && /usr/bin/c++ -I/<>/include -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -Wshadow -Wold-style-cast -Werror -std=gnu++11 -MD -MT
unittests/CMakeFiles/test_map.dir/map.cpp.o -MF CMakeFiles/test_map.dir/map.cpp.o.d -o CMakeFiles/test_map.dir/map.cpp.o -c
/<>/unittests/map.cpp
In file included from /<>/unittests/map.cpp:28:
/<>/unittests/map.hpp: In instantiation of ‘void test_map() [with
IArchive = cereal::BinaryInputArchive; OArchive = cereal::BinaryOutputArchive]’:
/<>/unittests/map.cpp:34:68: required from here
/<>/unittests/map.hpp:65:43: error: narrowing conversion of
‘random_value(gen)’ from ‘std::enable_if::type’ {aka ‘char’} to ‘signed
char’ [-Werror=narrowing]
65 | o_esplmap.insert({random_value(gen), { random_value(gen),
random_value(gen) }});
| ~~^
This was reported by a Fedora user[1] - please see the build log
in the upstream issue.
See buildd logs for more information.
I'm tempted to reduce the severity of this bug to important since the
binary packages of the said architectures never were built and thus the
criterion for "serious" is not really fulfilled. What do you think?
Another suggestion would be to exclude the two affected tests for the
said architectures for the moment - no idea how harmful this might be
in the end.
I'm not sure that we're seeing the same error as Fedora. It looks like
we're seeing a compile error while compiling the tests, rather than a test
failure.
Regards,
Scott
Bug#1021394: src:libcereal: FTBFS on arm, ppc64le, s390x
Package: src:libcereal
Version: 1.3.2+dfsg-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
libcereal 1.3.2+dfsg-3 FTBFS on arm, ppc64le, s390x. This seems to be
the relevant error:
[ 22%] Building CXX object unittests/CMakeFiles/test_map.dir/map.cpp.o
cd /<>/obj-aarch64-linux-gnu/unittests && /usr/bin/c++
-I/<>/include -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -Wshadow -Wold-style-cast -Werror
-std=gnu++11 -MD -MT unittests/CMakeFiles/test_map.dir/map.cpp.o -MF
CMakeFiles/test_map.dir/map.cpp.o.d -o CMakeFiles/test_map.dir/map.cpp.o -c
/<>/unittests/map.cpp
In file included from /<>/unittests/map.cpp:28:
/<>/unittests/map.hpp: In instantiation of ‘void test_map() [with
IArchive = cereal::BinaryInputArchive; OArchive = cereal::BinaryOutputArchive]’:
/<>/unittests/map.cpp:34:68: required from here
/<>/unittests/map.hpp:65:43: error: narrowing conversion of
‘random_value(gen)’ from ‘std::enable_if::type’ {aka ‘char’}
to ‘signed char’ [-Werror=narrowing]
65 | o_esplmap.insert({random_value(gen), {
random_value(gen), random_value(gen) }});
| ~~^
/<>/unittests/map.hpp: In instantiation of ‘void test_map() [with
IArchive = cereal::PortableBinaryInputArchive; OArchive =
cereal::PortableBinaryOutputArchive]’:
/<>/unittests/map.cpp:39:84: required from here
/<>/unittests/map.hpp:65:43: error: narrowing conversion of
‘random_value(gen)’ from ‘std::enable_if::type’ {aka ‘char’}
to ‘signed char’ [-Werror=narrowing]
/<>/unittests/map.hpp: In instantiation of ‘void test_map() [with
IArchive = cereal::XMLInputArchive; OArchive = cereal::XMLOutputArchive]’:
/<>/unittests/map.cpp:44:62: required from here
/<>/unittests/map.hpp:65:43: error: narrowing conversion of
‘random_value(gen)’ from ‘std::enable_if::type’ {aka ‘char’}
to ‘signed char’ [-Werror=narrowing]
/<>/unittests/map.hpp: In instantiation of ‘void test_map() [with
IArchive = cereal::JSONInputArchive; OArchive = cereal::JSONOutputArchive]’:
/<>/unittests/map.cpp:49:64: required from here
/<>/unittests/map.hpp:65:43: error: narrowing conversion of
‘random_value(gen)’ from ‘std::enable_if::type’ {aka ‘char’}
to ‘signed char’ [-Werror=narrowing]
See buildd logs for more information.
Also, please push the 1.3.2+dfsg-3 changes to git.
Thanks,
Scott
Bug#1021152: audacity: FTBFS on armel, s390x
Source: audacity Version: 3.2.0+dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, audacity 3.2.0+dfsg-1 FTBFS on armel and s390x. Tail of log for audacity on armel: /usr/include/c++/12/bits/stl_vector.h:1287:28: note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator >’ changed in GCC 7.1 1287 | _M_realloc_insert(end(), __x); | ~^~~~ In member function ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = LabelStruct; _Alloc = std::allocator]’, inlined from ‘void LabelTrack::Import(wxTextFile&)’ at /<>/src/LabelTrack.cpp:592:27: /usr/include/c++/12/bits/stl_vector.h:1287:28: note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator >’ changed in GCC 7.1 1287 | _M_realloc_insert(end(), __x); | ~^~~~ make[3]: Leaving directory '/<>/obj-arm-linux-gnueabi' make[2]: *** [CMakeFiles/Makefile2:1922: src/CMakeFiles/Audacity.dir/all] Error 2 make[2]: Leaving directory '/<>/obj-arm-linux-gnueabi' make[1]: *** [Makefile:159: all] Error 2 make[1]: Leaving directory '/<>/obj-arm-linux-gnueabi' dh_auto_build: error: cd obj-arm-linux-gnueabi && make -j8 "INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2 make: *** [debian/rules:47: binary-arch] Error 25 Tail of log for audacity on s390x: [ 65%] Building CXX object src/CMakeFiles/Audacity.dir/SseMathFuncs.cpp.o cd /<>/obj-s390x-linux-gnu/src && /usr/bin/c++ -DAUDACITY_DLL_API="" -DAUDIO_DEVICES_API="" -DAUDIO_GRAPH_API="" -DAudacity_EXPORTS -DBASIC_UI_API="" -DBUILDING_AUDACITY -DCMAKE -DCOMPONENTS_API="" -DEXCEPTIONS_API="" -DEXPERIMENTAL_CRASH_REPORT -DEXPERIMENTAL_DRAGGABLE_PLAY_HEAD -DEXPERIMENTAL_FULL_WASAPI -DEXPERIMENTAL_HALF_WAVE -DEXPERIMENTAL_KEY_VIEW -DEXPERIMENTAL_MIDI_OUT -DEXPERIMENTAL_MODULE_PREFS -DEXPERIMENTAL_NOISE_REDUCTION -DEXPERIMENTAL_NOTETRACK_OVERLAY -DEXPERIMENTAL_NYQUIST_SPLIT_CONTROL -DEXPERIMENTAL_PUNCH_AND_ROLL -DEXPERIMENTAL_SCIENCE_FILTERS -DEXPERIMENTAL_SCROLLING_LIMITS -DEXPERIMENTAL_SCRUBBING_SCROLL_WHEEL -DEXPERIMENTAL_SCRUBBING_SUPPORT -DEXPERIMENTAL_SPECTRAL_EDITING -DEXPERIMENTAL_SYNC_LOCK -DEXPERIMENTAL_THEMING -DEXPERIMENTAL_TWO_TONE_TIME_RULER -DEXPERIMENTAL_ZOOM_TOGGLE_BUTTON -DFFMPEG_SUPPORT_API="" -DFILES_API="" -DGRAPHICS_API="" -DHAVE_LRINT -DHAVE_LRINTF -DHAVE_MLOCK -DIPC_API="" -DMATH_API="" -DMODULE_MANAGER_API="" -DPREFERENCES_API="" -DPROJECT_API="" -DPROJECT_HISTORY_API="" -DPROJECT_RATE_API="" -DREGISTRIES_API="" -DSAMPLE_TRACK_API="" -DSCREEN_GEOMETRY_API="" -DSTRINGS_API="" -DSTRING_UTILS_API="" -DTHEME_API="" -DTHEME_RESOURCES_API="" -DTRACK_API="" -DTRANSACTIONS_API="" -DUSE_FFMPEG -DUSE_NYQUIST=1 -DUSE_PORTMIXER=1 -DUTILITY_API="" -DUUID_API="" -DWXUSINGDLL -DXML_API="" -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -I/<>/obj-s390x-linux-gnu/src/private -I/<>/include -I/<>/src -I/<>/libraries/lib-string-utils -I/<>/libraries/lib-uuid -I/<>/libraries/lib-project-rate -I/<>/libraries/lib-project -I/<>/libraries/lib-registries -I/<>/libraries/lib-preferences -I/<>/libraries/lib-utility -I/<>/libraries/lib-basic-ui -I/<>/libraries/lib-strings -I/<>/libraries/lib-components -I/<>/libraries/lib-exceptions -I/<>/libraries/lib-xml -I/<>/libraries/lib-files -I/<>/libraries/lib-audio-devices -I/<>/lib-src/portmixer/include -I/<>/libraries/lib-math -I/<>/libraries/lib-theme-resources -I/<>/libraries/lib-theme -I/<>/libraries/lib-sample-track -I/<>/libraries/lib-audio-graph -I/<>/libraries/lib-track -I/<>/libraries/lib-module-manager -I/<>/libraries/lib-ipc -I/<>/libraries/lib-project-history -I/<>/libraries/lib-screen-geometry -I/<>/libraries/lib-transactions -I/<>/libraries/lib-graphics -I/<>/libraries/lib-ffmpeg-support -I/<>/libraries/lib-sentry-reporting -I/<>/lib-src/libnyquist -isystem /usr/lib/s390x-linux-gnu/wx/include/gtk3-unicode-3.2 -isystem /usr/include/wx-3.2 -isystem /usr/include/lame -isystem /usr/include/lilv-0 -isystem /usr/include/sratom-0 -isystem /usr/include/sord-0 -isystem /usr/include/serd-0 -isystem /usr/include/suil-0 -isystem /usr/include/portSMF -isystem /usr/include/soundtouch -isystem /usr/include/glib-2.0 -isystem /usr/lib/s390x-linux-gnu/glib-2.0/include -isystem /usr/include/gtk-3.0 -isystem /usr/include/at-spi2-atk/2.0 -isystem /usr/include/at-spi-2.0 -isystem /usr/include/dbus-1.0 -isystem /usr/lib/s390x-linux-gnu/dbus-1.0/include -isystem /usr/include/gio-unix-2.0 -isystem /usr/include/cairo -isystem /usr/include/pango-1.0 -isystem /usr/include/harfbuzz -isystem /usr/include/fribidi -isystem /usr/include/atk-1.0 -isystem /usr/include/pixman-1 -isystem /usr/include/uuid -isystem /usr/include/freetype2 -isystem /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/libpng16 -isystem /usr/include/libmount -isystem /usr/include/blkid -g -O2 -ffile-prefix-map=/<>=.
Bug#1020779: slic3r-prusa: FTBFS on 32-bit arches
Source: slic3r-prusa
Version: 2.5.0+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
slic3r-prusa 2.5.0+dfsg-1 FTBFS on 32-bit arches (armhf, i386, mipsel).
Log snippet:
Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_8a1c7/fast && gmake[2]:
Entering directory
'/<>/obj-arm-linux-gnueabihf/CMakeFiles/CMakeTmp'
/usr/bin/gmake -f CMakeFiles/cmTC_8a1c7.dir/build.make
CMakeFiles/cmTC_8a1c7.dir/build
gmake[3]: Entering directory
'/<>/obj-arm-linux-gnueabihf/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_8a1c7.dir/src.cxx.o
/usr/bin/c++ -DCOMPILER_HAS_DEPRECATED_ATTR -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -g1 -Wdate-time -D_FORTIFY_SOURCE=2
-fext-numeric-literals -Wall -Wno-reorder -fPIE -std=gnu++17 -o
CMakeFiles/cmTC_8a1c7.dir/src.cxx.o -c
/<>/obj-arm-linux-gnueabihf/CMakeFiles/CMakeTmp/src.cxx
/<>/obj-arm-linux-gnueabihf/CMakeFiles/CMakeTmp/src.cxx: In
function ‘int main()’:
/<>/obj-arm-linux-gnueabihf/CMakeFiles/CMakeTmp/src.cxx:2:33:
warning: ‘int somefunc()’ is deprecated [-Wdeprecated-declarations]
2 | int main() { return somefunc();}
| ^~
/<>/obj-arm-linux-gnueabihf/CMakeFiles/CMakeTmp/src.cxx:1:37:
note: declared here
1 | __attribute__((__deprecated__)) int somefunc() { return 0; }
| ^~~~
Linking CXX executable cmTC_8a1c7
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_8a1c7.dir/link.txt
--verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -g1 -Wdate-time
-D_FORTIFY_SOURCE=2 -fext-numeric-literals -Wall -Wno-reorder -Wl,-z,relro
CMakeFiles/cmTC_8a1c7.dir/src.cxx.o -o cmTC_8a1c7
gmake[3]: Leaving directory
'/<>/obj-arm-linux-gnueabihf/CMakeFiles/CMakeTmp'
gmake[2]: Leaving directory
'/<>/obj-arm-linux-gnueabihf/CMakeFiles/CMakeTmp'
Source file was:
__attribute__((__deprecated__)) int somefunc() { return 0; }
int main() { return somefunc();}
dh_auto_configure: error: cd obj-arm-linux-gnueabihf && cmake
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON
-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix
Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON
-DCMAKE_INSTALL_LIBDIR=lib/arm-linux-gnueabihf -DBUILD_TESTING=1
-DCMAKE_BUILD_TYPE=Release
-DOPENVDB_FIND_MODULE_PATH=/usr/lib/arm-linux-gnueabihf/cmake/OpenVDB
-DSLIC3R_FHS=1 -DSLIC3R_WX_STABLE=1 -DSLIC3R_GTK=3 .. returned exit code 1
make[1]: *** [debian/rules:20: override_dh_auto_configure] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:17: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1020052: marked as pending in pycurl
Control: tag -1 pending Hello, Bug #1020052 in pycurl reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pycurl/-/commit/f07a9cbb6f54c81722c49edf930a8ed941f2a6d8 Fix FTBFS with newer setuptools (Closes: #1020052) (this message was generated automatically) -- Greetings https://bugs.debian.org/1020052
Bug#1019953: flamerobin: FTBFS on arm, i386, mips
Source: flamerobin
Version: 0.9.3.12-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
flamerobin 0.9.3.12-1 FTBFS on serveral arches (arm*, i386, mips*).
Relevant log snippets:
cd /<>/obj-aarch64-linux-gnu && /usr/bin/cmake -E cmake_depends
"Unix Makefiles" /<> /<>
/<>/obj-aarch64-linux-gnu /<>/obj-aarch64-linux-gnu
/<>/obj-aarch64-linux-gnu/CMakeFiles/IBPP.dir/DependInfo.cmake
--color=
make[3]: Leaving directory '/<>/obj-aarch64-linux-gnu'
make -f CMakeFiles/IBPP.dir/build.make CMakeFiles/IBPP.dir/build
make[3]: Entering directory '/<>/obj-aarch64-linux-gnu'
[ 0%] Building CXX object CMakeFiles/IBPP.dir/src/ibpp/_dpb.cpp.o
[ 1%] Building CXX object CMakeFiles/IBPP.dir/src/ibpp/_ibpp.cpp.o
/usr/bin/c++ -DFR_INSTALL_PREFIX=\"/usr\" -DIBPP_LINUX -DWXUSINGDLL
-D_FILE_OFFSET_BITS=64 -D__WXGTK__ -I/<>/res
-I/<>/src/ibpp -I/<>/src -isystem
/usr/lib/aarch64-linux-gnu/wx/include/gtk3-unicode-3.2 -isystem
/usr/include/wx-3.2 -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -pthread -std=gnu++14 -MD -MT
CMakeFiles/IBPP.dir/src/ibpp/_ibpp.cpp.o -MF
CMakeFiles/IBPP.dir/src/ibpp/_ibpp.cpp.o.d -o
CMakeFiles/IBPP.dir/src/ibpp/_ibpp.cpp.o -c /<>/src/ibpp/_ibpp.cpp
[ 2%] Building CXX object CMakeFiles/IBPP.dir/src/ibpp/_ibs.cpp.o
[ 3%] Building CXX object CMakeFiles/IBPP.dir/src/ibpp/_rb.cpp.o
/usr/bin/c++ -DFR_INSTALL_PREFIX=\"/usr\" -DIBPP_LINUX -DWXUSINGDLL
-D_FILE_OFFSET_BITS=64 -D__WXGTK__ -I/<>/res
-I/<>/src/ibpp -I/<>/src -isystem
/usr/lib/aarch64-linux-gnu/wx/include/gtk3-unicode-3.2 -isystem
/usr/include/wx-3.2 -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -pthread -std=gnu++14 -MD -MT
CMakeFiles/IBPP.dir/src/ibpp/_rb.cpp.o -MF
CMakeFiles/IBPP.dir/src/ibpp/_rb.cpp.o.d -o
CMakeFiles/IBPP.dir/src/ibpp/_rb.cpp.o -c /<>/src/ibpp/_rb.cpp
/usr/bin/c++ -DFR_INSTALL_PREFIX=\"/usr\" -DIBPP_LINUX -DWXUSINGDLL
-D_FILE_OFFSET_BITS=64 -D__WXGTK__ -I/<>/res
-I/<>/src/ibpp -I/<>/src -isystem
/usr/lib/aarch64-linux-gnu/wx/include/gtk3-unicode-3.2 -isystem
/usr/include/wx-3.2 -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -pthread -std=gnu++14 -MD -MT
CMakeFiles/IBPP.dir/src/ibpp/_dpb.cpp.o -MF
CMakeFiles/IBPP.dir/src/ibpp/_dpb.cpp.o.d -o
CMakeFiles/IBPP.dir/src/ibpp/_dpb.cpp.o -c /<>/src/ibpp/_dpb.cpp
/usr/bin/c++ -DFR_INSTALL_PREFIX=\"/usr\" -DIBPP_LINUX -DWXUSINGDLL
-D_FILE_OFFSET_BITS=64 -D__WXGTK__ -I/<>/res
-I/<>/src/ibpp -I/<>/src -isystem
/usr/lib/aarch64-linux-gnu/wx/include/gtk3-unicode-3.2 -isystem
/usr/include/wx-3.2 -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -pthread -std=gnu++14 -MD -MT
CMakeFiles/IBPP.dir/src/ibpp/_ibs.cpp.o -MF
CMakeFiles/IBPP.dir/src/ibpp/_ibs.cpp.o.d -o
CMakeFiles/IBPP.dir/src/ibpp/_ibs.cpp.o -c /<>/src/ibpp/_ibs.cpp
In file included from /<>/src/ibpp/ibpp.h:71,
from /<>/src/ibpp/_ibpp.h:23,
from /<>/src/ibpp/_rb.cpp:26:
/usr/include/c++/12/decimal/decimal:39:2: error: #error This file requires
compiler and library support for ISO/IEC TR 24733 that is currently not
available.
39 | #error This file requires compiler and library support for ISO/IEC TR
24733 \
| ^
/usr/include/c++/12/decimal/decimal:233:5: error: decimal floating-point not
supported for this target
233 | decimal32() : __val(0.e-101DF) {}
| ^
/usr/include/c++/12/decimal/decimal:319:5: error: decimal floating-point not
supported for this target
319 | decimal64() : __val(0.e-398dd) {}
| ^
/usr/include/c++/12/decimal/decimal:405:5: error: decimal floating-point not
supported for this target
405 | decimal128(): __val(0.e-6176DL) {}
| ^~
In file included from /usr/include/c++/12/decimal/decimal:492:
/usr/include/c++/12/decimal/decimal.h:127:9: error: decimal floating-point not
supported for this target
127 | __multiplier = 1.E-1DF;
| ^~~~
/usr/include/c++/12/decimal/decimal.h:131:7: error: decimal floating-point not
supported for this target
131 | __multiplier = 1.E1DF;
| ^~~~
/usr/include/c++/12/decimal/decimal.h:145:9: error: decimal floating-point not
supported for this target
145 | __multiplier = 1.E-1DF;
| ^~~~
/usr/include/c++/12/decimal/decimal.h:149:7: error: decimal floating-point not
supported for this target
149 | __multiplier = 1.E1DF;
| ^~~~
/usr/include/c++/12/decimal/decimal.h:163:9: error: decimal floating-point not
supported for this target
163 | __multiplier = 1.E-1DD;
Bug#1015733: ghc: ABI reproducibility broken in 9.0.2
Package: ghc Version: 9.0.2-3 Severity: serious Justification: Policy 4.15 Haskell ABI reproducibility is broken in ghc 9.0.2. If you rebuild the ghc-9.0.2-3 package repeatedly, the library packages that it provides (e.g., libghc-array-dev, libghc-base-dev, etc.) will have different hashes. Making this RC because it makes it impossible to rebuild the ghc package without rebuilding all 1000+ Haskell packages at the same time.
Bug#1015025: marked as pending in pytest-xdist
Control: tag -1 pending Hello, Bug #1015025 in pytest-xdist reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pytest-xdist/-/commit/58daacd2ce663e7bcdb54a93db3a723c0a6e9f79 Fix FTBFS due to _version.py path change (Closes: #1015025) (this message was generated automatically) -- Greetings https://bugs.debian.org/1015025
Bug#1011697: wxpython4.0: FTBFS with SIP 6.6
On Sat, 11 Jun 2022, Sebastiaan Couwenberg wrote: Upstream has changes to fix building with SIP 6.6: https://github.com/wxWidgets/Phoenix/pull/2179 But this is blocked because there is no SIP 6.6.2 release yet with many fixes for the new ply based parser. Yes, Phil (sip upstream maintainer) said that he plans a new sip release next week when the new version of Qt comes out. Scott
Bug#1011762: marked as pending in haskell-devscripts
Control: tag -1 pending Hello, Bug #1011762 in haskell-devscripts 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/haskell-team/haskell-devscripts/-/commit/3061a1b8bab9265488d2ce8ac1ea0d89fc13c655 Re-add separate configure/check/haddock targets (Closes: #1011762, bug#1011767, #1011764, #1011834, #1011873, #1011877, #1011915, #1011860, bug#1011855, #1011910, #1011896) (this message was generated automatically) -- Greetings https://bugs.debian.org/1011762
Bug#1011913: haskell-swish: FTBFS: make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25
On Sat, 28 May 2022, Jonas Smedegaard wrote: Control: reassign -1 haskell-devscripts Control: retitle -1 haskell-devscripts: DEB_ENABLE_TESTS ignored Control: affects -1 haskell-swish Quoting Lucas Nussbaum (2022-05-26 21:04:50) During a rebuild of all packages in sid, [haskell-swish] failed to build on amd64. [...] Running debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct Non-zero exit code 1. hlibrary.setup: No test suites enabled. Did you remember to configure with '--enable-tests'? haskell-swish built successfully when released in January, and contains this in debian/rules: DEB_ENABLE_TESTS = yes Perhaps this really is bug#1010179 and the "fix" only papered over the underlying problem: @Scott, did you test packages _enabling_ tests or only the default of having tests disabled? Hi Jonas, Actually, it looks like DEB_ENABLE_TESTS=yes had been broken in haskell-devscripts for quite some time (even before Felix's changes). If you look at the January build log for haskell-swish, the tests were not run at that time. In the case of haskell-swish, DEB_ENABLE_TESTS needs to be defined *before* including hlibrary.mk. After fixing that, it seems there are some missing test dependencies. Scott
Bug#1010739: marked as pending in haskell-devscripts
Control: tag -1 pending Hello, Bug #1010739 in haskell-devscripts 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/haskell-team/haskell-devscripts/-/commit/60dc01b0df75a500789046a96cb92aaeb27955bf Perform haddock recipe before build recipe (Closes: #1010739) Evidently, haddock wipes out some of the files created by the build recipe (specifically at least the in-place registration files in dist-ghc/package.conf.inplace), so move it before build. (this message was generated automatically) -- Greetings https://bugs.debian.org/1010739
Bug#1010739: haskell-distributive: FTBFS: doctests: : cannot satisfy -package distributive-0.6.2
Control: reassign -1 haskell-devscripts Control: affects -1 haskell-distributive On Sun, 8 May 2022, Daniel Schepler wrote: doctests: : cannot satisfy -package distributive-0.6.2 (use -v for more information) This is due to another regression in haskell-devscripts (the problem does not exist with haskell-devscripts 0.16.2). I'm not entirely sure of the cause yet. Scott
Bug#1010703: marked as pending in haskell-devscripts
Control: tag -1 pending Hello, Bug #1010703 in haskell-devscripts 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/haskell-team/haskell-devscripts/-/commit/1dffd753200d69b9b2201e3de0891d81f3a5d790 Fix parsing of DEB_SETUP_GHC*_CONFIGURE_ARGS (Closes: #1010703) Replace the broken shell expansion with calls to Text::ParseWords::shellwords() which seems to be the Perl way of parsing command line arguments into an array. (this message was generated automatically) -- Greetings https://bugs.debian.org/1010703
Bug#1005438: marked as pending in pygame
Control: tag -1 pending Hello, Bug #1005438 in pygame reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pygame/-/commit/ee23ea00fa9caedf8f3916e146cc3869785afda8 Update to new upstream release 2.1.2 (Closes: #973352, #1005438) (this message was generated automatically) -- Greetings https://bugs.debian.org/1005438
Bug#1006039: pytest-xdist: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13
Control: forwarded -1 https://github.com/pytest-dev/pytest-xdist/issues/735 On Tue, 22 Feb 2022, Lucas Nussbaum wrote: I'm not able to reproduce this, at least locally in sbuild. Possibly some transient error in unstable? Can you re-try? Hi Scott, I can reproduce it, but this looks like a random failure. Building in a loop, I get: log.1:Status: attempted log.2:Status: successful log.3:Status: successful log.4:Status: successful log.5:Status: attempted Ah, random failures. The best kind. ;) Since the build succeeds more than 50% of the time, can we lower the severity? Scott
Bug#1006039: pytest-xdist: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13
On Sat, 19 Feb 2022, Lucas Nussbaum wrote:
=== FAILURES ===
_ test_internal_errors_propagate_to_controller _
pytester =
def test_internal_errors_propagate_to_controller(pytester: pytest.Pytester)
-> None:
pytester.makeconftest(
"""
def pytest_collection_modifyitems():
raise RuntimeError("Some runtime error")
"""
)
pytester.makepyfile("def test(): pass")
result = pytester.runpytest("-n1")
result.stdout.fnmatch_lines(["*RuntimeError: Some runtime error*"])
E Failed: nomatch: '*RuntimeError: Some runtime error*'
E and: '= test session starts
=='
E and: 'platform linux -- Python 3.10.2, pytest-6.2.5, py-1.10.0,
pluggy-0.13.0'
E and: 'rootdir:
/tmp/pytest-of-user42/pytest-0/test_internal_errors_propagate_to_controller0'
E and: 'plugins: xdist-2.5.0, forked-1.4.0'
E and: 'gw0 I'
E and: 'gw0 [1]'
E and: ''
E and: 'INTERNALERROR> Traceback (most recent call last):'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/_pytest/main.py", line 269, in wrap_session'
E and: 'INTERNALERROR> session.exitstatus = doit(config, session)
or 0'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/_pytest/main.py", line 323, in _main'
E and: 'INTERNALERROR>
config.hook.pytest_runtestloop(session=session)'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286, in __call__'
E and: 'INTERNALERROR> return self._hookexec(self,
self.get_hookimpls(), kwargs)'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 92, in _hookexec'
E and: 'INTERNALERROR> return self._inner_hookexec(hook, methods,
kwargs)'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 335, in traced_hookexec'
E and: 'INTERNALERROR> return outcome.get_result()'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in get_result'
E and: 'INTERNALERROR> raise ex[1].with_traceback(ex[2])'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 52, in from_call'
E and: 'INTERNALERROR> result = func()'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 333, in '
E and: 'INTERNALERROR> outcome = _Result.from_call(lambda:
oldcall(hook, hook_impls, kwargs))'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 83, in '
E and: 'INTERNALERROR> self._inner_hookexec = lambda hook,
methods, kwargs: hook.multicall('
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 208, in _multicall'
E and: 'INTERNALERROR> return outcome.get_result()'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in get_result'
E and: 'INTERNALERROR> raise ex[1].with_traceback(ex[2])'
E and: 'INTERNALERROR> File
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in _multicall'
E and: 'INTERNALERROR> res = hook_impl.function(*args)'
E and: 'INTERNALERROR> File
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/dsession.py",
line 117, in pytest_runtestloop'
E and: 'INTERNALERROR> self.loop_once()'
E and: 'INTERNALERROR> File
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/dsession.py",
line 140, in loop_once'
E and: 'INTERNALERROR> call(**kwargs)'
E and: 'INTERNALERROR> File
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/dsession.py",
line 262, in worker_collectionfinish'
E and: 'INTERNALERROR> self.sched.schedule()'
E and: 'INTERNALERROR> File
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/scheduler/load.py",
line 257, in schedule'
E and: 'INTERNALERROR> self._send_tests(next(nodes), 1)'
E and: 'INTERNALERROR> File
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/scheduler/load.py",
line 269, in _send_tests'
E and: 'INTERNALERROR> node.send_runtest_some(tests_per_node)'
E and: 'INTERNALERROR> File
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/workermanage.py",
line 284, in send_runtest_some'
E and: 'INTERNALERROR> self.sendcommand("runtests",
indices=indices)'
E and: 'INTERNALERROR> File
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/workermanage.py",
line 300, in sendcommand'
E and: 'INTERNALERROR>
Bug#1002325: [Help] Re: python-envisage: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned exit code 13
On Thu, 10 Feb 2022, Andreas Tille wrote:
Control: tags -1 help
Hi,
I've updated python-envisage in Salsa[1] to the latest upstream version
and bumped its failing predepends to their according latest upstream and
fixed all bugs in those. For envisage I'm stumbling upon a Python3.10
related bug I'd like to ask for help:
...
==
ERROR: test_exclude_multiple
(envisage.tests.test_egg_plugin_manager.EggPluginManagerTestCase)
exclude multiple
--
Traceback (most recent call last):
File
"/build/python-envisage-6.0.1/.pybuild/cpython3_3.10_envisage/build/envisage/tests/test_egg_plugin_manager.py",
line 115, in test_exclude_multiple
self._add_eggs_on_path([self.egg_dir])
File
"/build/python-envisage-6.0.1/.pybuild/cpython3_3.10_envisage/build/envisage/tests/test_egg_based.py",
line 59, in _add_eggs_on_path
raise SystemError("Cannot find eggs %s" % errors)
SystemError: Cannot find eggs {}
I spent some time looking into this. The problem is that upstream
includes binary eggs (which are Python version specific) as part of its
test suite. The problem here is that there are no eggs included for
Python 3.10. Upstream is aware of this[1] but unfortunately, that patch
can't be applied because it is a binary patch. They have also later[2]
removed the binary eggs completely, but that patch can't be applied either
because it involves files that are not in the PyPI distribution. The best
solution might be do what Fedora did[3], but for that we'd probably have
to switch to using a GitHub tarball instead of the PyPI tarball because
the PyPI tarball is missing files.
Scott
[1]
https://github.com/enthought/envisage/commit/d29e6f438d16fc6ac6ede5381ba12d9849187b14
[2]
https://github.com/enthought/envisage/commit/6e5c7ba004e8700bd009c3d2b9444d543709a4d7
[3]
https://src.fedoraproject.org/rpms/python-envisage/c/a20fa2cf6fe0eaf7604394a8b93bf8d3b48bc599?branch=rawhide
Bug#997505: [Help] diskcache: FTBFS now even earlier due to Python3.10
On Mon, 29 Nov 2021, Scott Talbert wrote:
ERROR: py310: could not install deps [django>=2.2.*, pytest, pytest-cov,
pytest-django, pytest-xdist]; v =
InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip
install 'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1:
cd /build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c
/build/diskcache-5.2.1/tox.ini --sitepa
The actual error:
ERROR: Could not find a version that satisfies the requirement
typing-extensions>=3.6.4 (from importlib-metadata)
ERROR: No matching distribution found for typing-extensions>=3.6.4
That is a really strange error. importlib-metadata requires
typing-extenstions>=3.6.4, but it's supposed to be only for python < 3.8.
Almost seems like a pip bug when comparing version strings? Perhaps its
confused with the two-digits in python 3.10?
Yep, I confirmed this is a bug in pip (and apparently a downstream one)
and filed a separate bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000826
Scott
Bug#997505: [Help] diskcache: FTBFS now even earlier due to Python3.10
On Mon, 29 Nov 2021, Andrey Rahmatullin wrote:
On Mon, Nov 29, 2021 at 05:58:47PM +0100, Andreas Tille wrote:
ERROR: py310: could not install deps [django>=2.2.*, pytest, pytest-cov, pytest-django,
pytest-xdist]; v = InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip
install 'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd
/build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c
/build/diskcache-5.2.1/tox.ini --sitepa
The actual error:
ERROR: Could not find a version that satisfies the requirement
typing-extensions>=3.6.4 (from importlib-metadata)
ERROR: No matching distribution found for typing-extensions>=3.6.4
That is a really strange error. importlib-metadata requires
typing-extenstions>=3.6.4, but it's supposed to be only for python < 3.8.
Almost seems like a pip bug when comparing version strings? Perhaps its
confused with the two-digits in python 3.10?
Scott
Bug#997505: [Help] diskcache: FTBFS now even earlier due to Python3.10
On Mon, 29 Nov 2021, Andreas Tille wrote:
Control: tags -1 help
Hi,
currently I'm running into
ERROR: py310: could not install deps [django>=2.2.*, pytest, pytest-cov, pytest-django,
pytest-xdist]; v = InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip
install 'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd
/build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c
/build/diskcache-5.2.1/tox.ini --sitepa
Any help would be really welcome
Can you post the full build log somewhere?
Scott
Bug#977055: marked as pending in apipkg
Control: tag -1 pending Hello, Bug #977055 in apipkg reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/apipkg/-/commit/38978227f0dc12b29291a86195cb38b3cd448625 Fix FTBFS with pytest 6 (Closes: #977055) (this message was generated automatically) -- Greetings https://bugs.debian.org/977055
Bug#977082: marked as pending in pytest-xdist
Control: tag -1 pending Hello, Bug #977082 in pytest-xdist reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pytest-xdist/-/commit/77f2ba1d8a937797ada572034338641dd5dedca8 Update to new upstream release 2.2.0 (Closes: #977082) (this message was generated automatically) -- Greetings https://bugs.debian.org/977082
Bug#978268: marked as pending in pytest-xdist
Control: tag -1 pending Hello, Bug #978268 in pytest-xdist reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pytest-xdist/-/commit/3db26534a4391ae41fbd2eac72264fba7a83856c Add src/xdist/_version.py to d/clean (Closes: #978268) (this message was generated automatically) -- Greetings https://bugs.debian.org/978268
Bug#978197: marked as pending in apipkg
Control: tag -1 pending Hello, Bug #978197 in apipkg reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/apipkg/-/commit/30df546d008e297b4d0ace18ea4b5a11e957fa7f Add src/apipkg/version.py to d/clean (Closes: #978197) (this message was generated automatically) -- Greetings https://bugs.debian.org/978197
Bug#976845: wxpython-tools needs source upload for Python 3.9 transition
On Wed, 9 Dec 2020, Adrian Bunk wrote: They probably don't. The tools are really just setuptools entry point scripts. The dependency is just coming from the shebang in those scripts I believe. In that case it should be fixed with override_dh_python3: dh_python3 --shebang=/usr/bin/python3 Thanks for that tip! Scott
Bug#976845: wxpython-tools needs source upload for Python 3.9 transition
On Tue, 8 Dec 2020, Adrian Bunk wrote: In a more general note, do the tools have to use the versioned interpreter instead of python3? They probably don't. The tools are really just setuptools entry point scripts. The dependency is just coming from the shebang in those scripts I believe. Scott
Bug#970818: mrpt: FTBFS on mipse64el: E: Build killed with signal TERM after 150 minutes of inactivity
On Sat, 26 Sep 2020, José Luis Blanco-Claraco wrote: On Fri, Sep 25, 2020 at 10:50 PM Sebastian Ramacher wrote: Reducing the optimization level on mips64el might help to reduce the compile time. Alternatively, if possible, one could split the source files into smaller ones. Hmmm... great idea! In fact, there was already a piece of logic in debian/rules but was only active in "mipsel", I have updated it upstream via this commit/patch: https://github.com/MRPT/mrpt/commit/8d60d8b5bc6e50e605c965ace165837840fb4c34 Do you think it might be worth submitting version 1:2.1.0-2 via a patch? @Scott: Should I upload an entire new package to mentors.debian.net, or would it be enough to send our the patch file, if you are willing to sponsor the new upload? If you don't mind, please do a new package upload to mentors. Thanks, Scott
Bug#966289: Reassign
Control: reassign -1 ftp.debian.org
Bug#966289: (no subject)
Control: reassign -1 ftp.debian.org
Bug#966289: (no subject)
reassign -1 ftp.debian.org
Bug#936146: archivemail - Python 3 porting
On Mon, 27 Jul 2020, Sandro Tosi wrote: On Thu, 28 May 2020 13:56:59 -0400 (EDT) Scott Talbert wrote: On Tue, 26 May 2020, Jonathan Dowland wrote: archivemail seems to be a good candidate to RM due to dead upstream. However, it still has a relatively high popcon, so people seem to be using it. I'm willing to take a stab at porting to Python 3 if anyone is available to test it? The port effort doesn't look that bad at first glance, but I don't use this package. I'm happy to test anything you produce, but I'd warn you that I think it's quite a significant piece of work. From what I remember when I last looked at hacking a feature into it (#736327), archivemail uses the older of two different APIs provided by the python "mailbox" library, and only the newer one was carried forward to Python 3. So moving away from that older API is a big part of the work. You were right. This was harder than I expected. :) Mainly it is exactly as you described - the rfc822.Message class (which doesn't exist in Python 3) does not map exactly to the email.message.Message class. I'm stuck at the moment with figuring out how to calculate the message size. In rfc822.Message, you could access the file handle directly and get the size that way. do you have any plan on completing this port? I'm not a user of archivemail but it looks like it should be removed, not salvaged: * no new upstream releases since 2011 (!) * last upload to debian in 2014 * retired from fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1777616 maybe it's time to let it go? If i dont hear otherwise in a week, i'll file for its removal No, I kind of gave up. It did turn out to be harder than I expected, and some of the APIs in the older email APIs don't exist in the new ones, so it wasn't clear what to do there. I would say it can go, but I don't use it so my opinion doesn't matter much. Scott
Bug#937519: RM pyrex?
Control: reassign -1 ftp.debian.org Control: retitle -1 RM: pyrex -- RoQA; dead upstream; no rdeps; blocking py2 removal
Bug#937519: RM pyrex?
Hi, I believe I removed the last rdep on pyrex by switching xmms2 to cython. Any objections to RM pyrex now? Thanks, Scott
Bug#936146: archivemail - Python 3 porting
On Tue, 26 May 2020, Jonathan Dowland wrote: archivemail seems to be a good candidate to RM due to dead upstream. However, it still has a relatively high popcon, so people seem to be using it. I'm willing to take a stab at porting to Python 3 if anyone is available to test it? The port effort doesn't look that bad at first glance, but I don't use this package. I'm happy to test anything you produce, but I'd warn you that I think it's quite a significant piece of work. From what I remember when I last looked at hacking a feature into it (#736327), archivemail uses the older of two different APIs provided by the python "mailbox" library, and only the newer one was carried forward to Python 3. So moving away from that older API is a big part of the work. You were right. This was harder than I expected. :) Mainly it is exactly as you described - the rfc822.Message class (which doesn't exist in Python 3) does not map exactly to the email.message.Message class. I'm stuck at the moment with figuring out how to calculate the message size. In rfc822.Message, you could access the file handle directly and get the size that way. Scott
Bug#936804: knockpy - python3
Hi, Looks like someone did a patch to port knockpy to Python 3: https://github.com/guelfoweb/knock/pull/71 Regards, Scott
Bug#936465: Remove python-ecryptfs?
Does it make sense to just remove the python-ecrpyptfs bindings? They don't seem to have any reverse dependencies and popcon is very low. Thanks, Scott
Bug#936146: archivemail - Python 3 porting
archivemail seems to be a good candidate to RM due to dead upstream. However, it still has a relatively high popcon, so people seem to be using it. I'm willing to take a stab at porting to Python 3 if anyone is available to test it? The port effort doesn't look that bad at first glance, but I don't use this package. Scott
Bug#945739: symeig - RM?
Control: reassign -1 ftp.debian.org Control: retitle -1 RM: symeig -- RoQA; package obsolete; blocking py2 removal
Bug#945739: symeig - RM?
Hi, It seems that symeig has no (longer?) reverse depends and it seems to be abandoned upstream. Is the best solution just to remove it? Thanks, Scott
Bug#933439: amule: Please rebuild against wxWidgets GTK 3 package
On Thu, 7 May 2020, Sandro Tosi wrote: Does the crash you referenced here require connecting to file sharing networks to reproduce? hard to say, as it crashed early on in the start up process (and also because i dont really remember because several months have passed). Clearly there's always a "risk" when using a file sharing software that it connects to the network. that being said, there's no _legal_ issue is you dont have anything in download/upload: even if amule connects to the enkey/kademlia networks it has nothing so share or download, so that's just an empty client with no implications for the IP address it connected to. Do you mind trying again with the latest wxwidgets3.0 release? I just uploaded a new upstream release (3.0.5.1) yesterday, so if it was possibly a wx issue, it may have been fixed. Also, there is a very similar amule bug report (crash) from someone who was still running the GTK 2 build of wx, so it would be good to check whether this is really something just seen when when running the GTK 3 build. Scott
Bug#945705: selenium-firefoxdriver: Python2 removal in sid/bullseye
Control: reassign -1 ftp.debian.org Control: retitle -1 RM: selenium-firefoxdriver -- RoQA; package non-functional; blocking py2 removal Package no longer works with current Firefox and is blocking Python 2 removal. Maintainer requests removal.
Bug#945705: selenium-firefoxdriver: Python2 removal in sid/bullseye
On Fri, 29 Nov 2019, Sascha Girrulat wrote: Source: selenium-firefoxdriver Version: 3.14.1-1 Severity: normal Tags: sid bullseye Hi, the firefoxdriver supports only firefox version up to 52.0 and does not work with the current version of firefox anymore. That's why the removal is fine. I'm sorry, i thought that the removal is already done but for some reasons the package is still there. Hi, So you want to remove selenium-firefoxdriver package from Debian? Regards, Scott
Bug#933439: amule: Please rebuild against wxWidgets GTK 3 package
On Wed, 6 May 2020, Sandro Tosi wrote: Any update on moving amule to use libwxgtk3.0-gtk3-dev? amule is one of the last couple of packages keeping the gtk2 wx package in unstable (as cruft). We keep getting bug reports about those cruft packages periodically. Sadly no: upstream hasnt ported amule to WX GTK3 and it doesnt look like it's gonna happen anytime soon (help with the port is of course welcome, probably better to sync upstream if someone wants to lend a hand) so feel free to ask FTP Masters to force the decruft Does the crash you referenced here require connecting to file sharing networks to reproduce? Scott
Bug#933439: amule: Please rebuild against wxWidgets GTK 3 package
On Tue, 1 Oct 2019, Olly Betts wrote: Switching to the GTK 3 version may be as simple as: 1) Update your Build-Depends libwxgtk3.0-dev -> libwxgtk3.0-gtk3-dev libwxgtk-media3.0-dev -> libwxgtk-media3.0-gtk3-dev 2) Rebuild 3) Test i tried this but it failed with this segfault: [...] Thread 1 "amule" received signal SIGSEGV, Segmentation fault. 0x771d8c1a in wxWindow::DoClientToScreen(int*, int*) const () from /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0 That sounds suspiciously similar to this bug, reported as happening when using the GTK2 flavour of wxWidgets: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935698 Any update on moving amule to use libwxgtk3.0-gtk3-dev? amule is one of the last couple of packages keeping the gtk2 wx package in unstable (as cruft). We keep getting bug reports about those cruft packages periodically. Thanks, Scott
Bug#942988: displaycal: Python2 removal in sid/bullseye
On Wed, 22 Apr 2020, Christian Marillat wrote: On 17 avril 2020 11:32, Scott Talbert wrote: [...] It looks like upstream doesn't seem to be making much progress on this. Do you think that we need to start working on Python 3 support ourselves? Duplicate work is a bad idea. Otherwise upstream is still active in displaycal forums (18/04/2020) : https://hub.displaycal.net/forums/topic/battery-life/ It wouldn't be duplicative work. It could be provided to upstream. There doesn't appear to be any upstream commits since 2020-01-14... Scott
Bug#942988: displaycal: Python2 removal in sid/bullseye
On Wed, 23 Oct 2019 07:58:05 +0200 Christian Marillat wrote: > On 23 oct. 2019 02:33, mo...@debian.org wrote: > > > Source: displaycal > > Version: 3.8.7.1-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 > > From https://hub.displaycal.net/issue/17813/ > > , > | Around end of the year-ish is also the latest date I plan to have moved > everything to Py3 > ` It looks like upstream doesn't seem to be making much progress on this. Do you think that we need to start working on Python 3 support ourselves? Scott
Bug#950221: salsa: Please transfer natsort from debian to python-team/modules
On Sat, 14 Mar 2020, Adrian Bunk wrote: Hi, please transfer natsort from debian to python-team/modules, see #950221 for background. Hello again Salsa admins. Can you please transfer natsort to python-team/modules? I would like to get natsort fixed ASAP. Thanks, Scott
Bug#936630: Re: Bug#936630: gnumed-client: upstream has (unreleased) py3 support
On Wed, 5 Feb 2020, Scott Talbert wrote: It's done, there's even a release 1.8.rc3. I need to convince myself to release 1.8.0 proper :-) Please convince yourself and I'll upload. Agree, consider this another prod to convince yourself. :) The wxPython 3.0 reverse depends are dwindling down to half a dozen or so, so it is getting closer to removal time. BTW, the gnumed website seems to be having some problems. Another gentle ping. :) gnumed-client is now only one of 3 remaining rdeps of wxpython3.0. I see you just did an rc3 of gnumed-client so perhaps a release is close. Scott
Bug#938608: RM svn-workbench
reassign -1 ftp.debian.org retitle -1 RM: svn-workbench -- RoQA; dead upstream; low popcon; blocking py2 removal
Bug#939181: RM cycle
reassign -1 ftp.debian.org retitle -1 RM: cycle -- RoQA; dead upstream; unmaintained; low popcon; blocking py2 removal
