Bug#1071548: nmu: libwx-perl_1:0.9932-8+b7
Control: reopen -1 On Tue, 21 May 2024, Emilio Pozuelo Monfort wrote: On 21/05/2024 01:21, Scott Talbert wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libwx-p...@packages.debian.org Control: affects -1 + src:libwx-perl User: release.debian@packages.debian.org Usertags: binnmu nmu libwx-perl_1:0.9932-8+b7 . ANY . unstable . -m "Rebuild with wxwidgets3.2 (3.2.5+dfsg-1)" (Please schedule this to rebuild after the corresponding libalien-wxwidgets-perl binNMU.) Scheduled. This one needs another binNMU also, depwaited on libalien-wxwidgets-perl 0.69+dfsg-6+b9. Thanks, Scott
Bug#1071547: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b7
Control: reopen -1 On Tue, 21 May 2024, Emilio Pozuelo Monfort wrote: On 21/05/2024 01:20, Scott Talbert wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl User: release.debian@packages.debian.org Usertags: binnmu nmu libalien-wxwidgets-perl_0.69+dfsg-6+b7 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.5+dfsg-1)" (Please schedule this to rebuild with wxwidgets3.2 (3.2.5+dfsg-1)) Scheduled. Hello, Unfortunately, it seems this was scheduled to execute immediately, rather than wait for wxwidgets3.2 (3.2.5+dfsg-1). So we're going to need another binNMU now that wx has been uploaded. Regards, Scott
Bug#1071548: nmu: libwx-perl_1:0.9932-8+b7
Package: release.debian.org Severity: normal X-Debbugs-Cc: libwx-p...@packages.debian.org Control: affects -1 + src:libwx-perl User: release.debian@packages.debian.org Usertags: binnmu nmu libwx-perl_1:0.9932-8+b7 . ANY . unstable . -m "Rebuild with wxwidgets3.2 (3.2.5+dfsg-1)" (Please schedule this to rebuild after the corresponding libalien-wxwidgets-perl binNMU.)
Bug#1071547: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b7
Package: release.debian.org Severity: normal X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl User: release.debian@packages.debian.org Usertags: binnmu nmu libalien-wxwidgets-perl_0.69+dfsg-6+b7 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.5+dfsg-1)" (Please schedule this to rebuild with wxwidgets3.2 (3.2.5+dfsg-1))
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#1066962: wxwidgets3.2: 1 testsuite failed on loong64
On Sat, 16 Mar 2024 15:21:57 +0800 zhangdandan wrote: > Source: wxwidgets3.2 > Version: 3.2.4+dfsg-3.1 > Severity: serious > Tags: help > User: debian-loonga...@lists.debian.org > Usertags: loong64 > > Dear maintainers, > > The following test failed on the loongarch64 architecture, compiled 20 > hours ago (March 16th). > ``` > - -- > URLTestCase > GetInputStream > - -- > ./uris/url.cpp:37 > ... > > ./uris/url.cpp:89: FAILED: > REQUIRE( in_stream ) > with expansion: > 0 > > === > test cases: 312 | 311 passed | 1 failed > assertions: 1230238 | 1230237 passed | 1 failed > > make[1]: *** [debian/rules:89: override_dh_auto_test] Error 1 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:22: binary-arch] Error 2 > dpkg-buildpackage: error: debian/rules binary-arch subprocess returned > exit status 2 > ``` > The full build log can be found at > https://buildd.debian.org/status/package.php?p=wxwidgets3.2=sid. > > I have reproduced the above testsuite issues on my local loong64 rootfs > environment. > After analyzing, I don't think this error has anything to do with > architecture. > So please focus on this test case failure. > > thanks, > Dandan Zhang Hello, This particular test is supposed to be skipped if the build host doesn't have network connectivity. Does the loong64 buildd have network connectivity (unlike the other buildd's)? Unfortunately, there doesn't appear to be a loong64 porterbox, so I'm unable to look into why this is failing. Regards, Scott
Bug#1065007: pycurl: Please reconsider SSL choice (OpenSSL instead of GnuTLS)
On Wed, 28 Feb 2024, Boyuan Yang wrote: Source: pycurl Version: 7.45.2-7 Severity: normal X-Debbugs-CC: s...@techie.net Dear Debian pycurl maintainer, I was made aware of issues encountered by multiple users due to pycurl using GnuTLS instead of OpenSSL. Reviewing https://bugs.debian.org/515200 , it looks like the only reason of not using OpenSSL is the old OpenSSL licensing issue in the past. With OpenSSL 3.0 and later, linking against OpenSSL is obviously no longer problematic due to license switching to Apache-2.0. As a result, I am once again requesting using OpenSSL for SSL implementation for pycurl or at least adding an option for users to select. Currently I believe several options exist: 1) Switch the default package python3-pycurl to use OpenSSL. 2) Add a new binary package python3-pycurl-openssl, which is linked to OpenSSL. 3) Add binary packages python3-pycurl-openssl and python3-pycurl-gnutls, and let python3-pycurl to be an empty dependency package that may default to a certain implementation of your choice. In any case, the binary packages providing the same files and the same functionalities shall mutually conflict with each other. If you need patches for any of the choices, please let me know. Please also let me know if you have any comments. If needed, I can make package uploads via Team upload. Thanks! Thanks for CC'ing me on the bug report. I don't have any objections to rebuilding pycurl with openssl. I don't see a lot of value in having the added complexity of building both versions, so I'm fine with just switching to openssl. I'm in the middle of a new upstream release right now, but I'll plan to switch it after that. 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#1060711: python3-wxgtk4.0: Library dependency too lenient
On Mon, 22 Jan 2024, Matthias Urlichs wrote: On 17.01.24 15:01, Scott Talbert wrote: On Wed, 17 Jan 2024, Matthias Urlichs wrote: On 16.01.24 23:58, Scott Talbert wrote: Do I understand correctly that you installed the python3-wxgtk4.0 4.2.1+dfsg-3 binary package from Debian Testing into a Debian 12 system and that's how you encountered this error? Yes. So? Mix+match from stable+testing is rather common when you're developing stuff, and Policy 3.5 doesn't say "umm well that only applies for dependencies from the same release". Sorry, but that's not generally supported, at least for wxWidgets related packages. Sometimes we change compile options and other things that change the ABI. I noticed … However, perhaps you misunderstood. I'm not asking for "support mix and match of wx*-related packages". I'm asking for "support mix+match between releases; if and when that doesn't work, please set the dependencies so that the user can't install a mix-and-match system in the first place". I didn't misunderstand - you're asking for mis+match of wx-related (to include wxWidgets and wxPython) packages between releases, which isn't supported. wxPython is a Python wrapper for wxWidgets, so it is by necessity tightly coupled with wxWidgets. I'll try to find a way to tighten wxPython's dependency on be >= the wxWidgets it was compiled with. See also: https://lists.debian.org/debian-devel/2024/01/msg00266.html — NB, please disregard my snarky "go away" pseudo-quote there. That was not intended to reflect your reply here. Yes, I saw that. Scott
Bug#1060708: python3-wxgtk4.0: Package doesn't import
On Sat, 13 Jan 2024, Matthias Urlichs wrote: Package: python3-wxgtk4.0 Version: 4.2.0+dfsg-3 Severity: important X-Debbugs-Cc: sm...@smurf.noris.de /usr/lib/python3/dist-packages/wx/__init__.py contains: from wx.core import * del core del wx This doesn't work on my system. "wx.core" does *not* export a symbol named "core", thus the "del core" fails. Deleting the "del core" part fixes the problem. -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (750, 'stable'), (700, 'testing'), (650, 'oldstable'), (600, 'oldoldstable'), (500, 'stable-security'), (500, 'oldstable-security'), (500, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 Versions of packages python3-wxgtk4.0 depends on: ii libc62.36-9+deb12u3 ii libgcc-s112.2.0-14 ii libstdc++6 13.2.0-9 ii libwxbase3.2-1 3.2.4+dfsg-1 ii libwxgtk-gl3.2-1 3.2.4+dfsg-1 ii libwxgtk3.2-13.2.2+dfsg-2 ii python3 [python3-supported-min] 3.11.2-1+b1 ii python3-numpy1:1.24.2-1 ii python3-pil 9.4.0-1.1+b1 ii python3-six 1.16.0-4 Can you provide any additional details that may be relevant to reproducing this problem? I'm going to assume this is probably related to your other bug where you seem to be mixing and matching packages from testing and bookworm? Scott
Bug#1060711: python3-wxgtk4.0: Library dependency too lenient
On Sat, 13 Jan 2024, Matthias Urlichs wrote: Package: python3-wxgtk4.0 Version: 4.2.1+dfsg-3 Severity: normal X-Debbugs-Cc: sm...@smurf.noris.de Installing the version from Testing says import wx.core Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/wx/__init__.py", line 17, in from wx.core import * File "/usr/lib/python3/dist-packages/wx/core.py", line 12, in from ._core import * ImportError: /usr/lib/python3/dist-packages/wx/_core.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN13wxRadioButtonD2Ev, version WXU_3.2 due to its dependency on libwxgtk3.2-1, which apparently needs to be >= 3.2.4 instead of 3.2.2. Semantic versioning appears to be overrated. :-( Hello Matthias, Do I understand correctly that you installed the python3-wxgtk4.0 4.2.1+dfsg-3 binary package from Debian Testing into a Debian 12 system and that's how you encountered this error? Scott
Bug#1057852: haskell-pandoc: please upgrade to at least v3.1.2
On Sat, 09 Dec 2023 17:16:41 +0100 Jonas Smedegaard wrote: > Source: haskell-pandoc > Version: 3.0.1-3 > Severity: normal > Tags: upstream > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Pandoc 3.0.1 is almost a year old. > > It seems that upgrading to 3.1.2 involves no upgrades to any of its > dependencies, and upgrading further involves only few dependencies: > > * upgrade to 3.1.2 > * upgrade to 3.1.3 > when needed Haskell libraries are in Debian: > + typst >= 0.1 && < 0.2 > * upgrade to 3.1.4 > when needed Haskell libraries are in Debian: > + crypton-connection >= 0.3.1 && < 0.4 > * upgrade to 3.1.6.2 > when needed Haskell libraries are in Debian: > + typst >= 0.3.2.0 && < 0.3.3 Replying here as per your request. Unfortunately, updating to haskell-pandoc 3.1.2 does not involve updating no dependencies - it requires an update to pandoc-lua-engine, which requires adding two new packages, isocline and hslua-repl. I went ahead and added these packages, as well as typst, so we should be able to update to 3.1.3 soon. Adding crypton-connection is going to be a bit more challenging as it requires an update to tls, which is used by several other packages, so I'm not sure if that's going to be easy. BTW, you didn't really address my question about updating the version of src:haskell-pandoc in relation to the version of src:pandoc (having nothing to do with the dependencies of src:haskell-pandoc). Just the version number. Scott
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#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3
On Sat, 18 Nov 2023, Cyril Brulebois wrote: Scott Talbert (2023-11-16): Scott Talbert (2023-11-13): Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.4+dfsg-1)" This looks like a redux of #1054146, with libwx-perl also needing a binNMU (after the libalien-wxwidgets-perl one)? Yeah, I did at least file both at the same time this round though :) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055908 I was trying to suggest filing both in the same request, to have them scheduled in one go. I tried to figure out how to do that with reportbug, but I did not see an obvious way to do it. For the future, how do I do that? Hand-written bug report? Scott
Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3
On Thu, 16 Nov 2023, Cyril Brulebois wrote: Hi, Scott Talbert (2023-11-13): Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.4+dfsg-1)" This looks like a redux of #1054146, with libwx-perl also needing a binNMU (after the libalien-wxwidgets-perl one)? Yeah, I did at least file both at the same time this round though :) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055908 Scott
Bug#1055908: nmu: libwx-perl_1:0.9932-8+b2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libwx-p...@packages.debian.org Control: affects -1 + src:libwx-perl nmu libwx-perl_1:0.9932-8+b2 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.4+dfsg-1)"
Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.4+dfsg-1)"
Bug#1054146: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b2
On Thu, 19 Oct 2023, Cyril Brulebois wrote: Indeed, libwx-perl has to be binMNU'd next. Was waiting for the s390x build of libalien-wxwidgets-perl, but went ahead and submitted the binNMU request for libwx-perl anyway so we can get other arches fixed. It would make sense to mention both packages from the get-go, we have dep-waits to ensure one finishes before the other one starts? My bad, I will do that next time. PS, what on the d-i uses libwx-perl? The unifont-bin build-dep pulls it. Interesting. Getting a bit off-topic here, but it probably would be good to see if that dependency could be removed. libwx-perl is unmaintained upstream - I've basically been maintaining it downstream, mainly just to keep it compiling, but not much more. Regards, Scott
Bug#1054146: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b2
On Thu, 19 Oct 2023, Cyril Brulebois wrote: Scott Talbert (2023-10-17): Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl nmu libalien-wxwidgets-perl_0.69+dfsg-6+b2 . ANY . unstable . -m "Rebuild against libwxgtk3.2-dev 3.2.3+dfsg-1" While libalien-wxwidgets-perl shows up on the auto-upperlimit-libwxgtk3.2-dev tracker, libwx-perl doesn't and this binNMU broke libwx-perl's installability, also breaking d-i builds. Package: libalien-wxwidgets-perl Provides: wxperl-gtk-3-2-3-uni-gcc-3-4 Package: libwx-perl Depends: […], wxperl-gtk-3-2-2-uni-gcc-3-4, […] Indeed, libwx-perl has to be binMNU'd next. Was waiting for the s390x build of libalien-wxwidgets-perl, but went ahead and submitted the binNMU request for libwx-perl anyway so we can get other arches fixed. PS, what on the d-i uses libwx-perl? Regards, Scott
Bug#1054203: nmu: libwx-perl_1:0.9932-8+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libwx-p...@packages.debian.org Control: affects -1 + src:libwx-perl nmu libwx-perl_1:0.9932-8+b1 . ANY . unstable . -m "Rebuild against libwxgtk3.2-dev 3.2.3+dfsg-1"
Bug#1054146: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl nmu libalien-wxwidgets-perl_0.69+dfsg-6+b2 . ANY . unstable . -m "Rebuild against libwxgtk3.2-dev 3.2.3+dfsg-1"
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: 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#1043284: RM: haskell-gi-gtk [armhf] -- ROM; FTBFS on armhf; likely GHC bug
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: haskell-gi-...@packages.debian.org Control: affects -1 + src:haskell-gi-gtk
Bug#1039474: ghc: GHCi sometimes segfaults
On Mon, 26 Jun 2023, Gard Spreemann wrote: GHCi seems to segfault randomly every now and then, after seemingly failing to allocate memory for simple operations, e.g.: $ ghci GHCi, version 9.0.2: https://www.haskell.org/ghc/ :? for help ghci> 750+850 1600 ghc: mmap 4096 bytes at (nil): Cannot allocate memory ghc: Try specifying an address with +RTS -xm -RTS zsh: segmentation fault ghci I've run into the same issue as well, mostly while trying to compile using clash. It seems that a kernel regression may be partly to blame as well, as observed in this Arch forum thread [1]. It may or may not be fixed by a kernel fix as well (I haven't tested it myself). Regards, Scott [1] https://bbs.archlinux.org/viewtopic.php?id=282429
Bug#1035279: wxpython4.0: please add autopkgtests (to add coverage for python3-numpy)
On Sun, 30 Apr 2023, Sandro Tosi wrote: For these reasons, please add "meaningful" autopkgtests to this package, which usually means running the upstream unittests. Hi Sandro, I do plan to enable wxPython's unittests eventually. However, they are currently unreliable/flaky, so that problem needs to be resolved first. Do note that wxPython's use of numpy is very minimal (it's only used by a few of the pure-python classes), so wxPython's unittests would not add a lot of meaningful test converage for numpy. Regards, Scott
Bug#1023519: python3-wxgtk4.0: Windows do not follow "dark" mode in Gnome
Control: reassign -1 src:wxwidgets3.2 Control: severity -1 wishlist On Sat, 5 Nov 2022, Matthias Brennwald wrote: Package: python3-wxgtk4.0 Version: 4.2.0+dfsg-1 Severity: normal X-Debbugs-Cc: mbren...@gmail.com Dear Maintainer, If "dark" mode is active in GNOME, GUI windows (and other GUI elements) created with python3-wxgtk4.0 are not painted in "dark" mode. Instead, they are painted using the standard "non-dark" mode. Hi Matthias, wxPython doesn't have anything to do with respect to dark mode, so reassigning this feature request to wxWidgets. While evaluating this issue, it seems even a lot of native Gnome/GTK apps do not even provide a dark mode (e.g., even the gtk-demo application doesn't). So it seems there is a lot of work still to be done here. Regards, Scott
Bug#980151: python3-wxgtk4.0: Window content does not always get painted correctly with Wayland
On Fri, 15 Jan 2021, Matthias Brennwald wrote: After creating and showing a new wxPython window/frame, the content of the window/frame does not always get painted completely. As far as I can tell, this happens mainly with windows/frames that contain a matplotlib panel. I tried version 4.1 of wxPython (using the pip3 installer), and the issue does no occur there. Hello Matthias, wxPython has been updated to v4.2.1 (and wxWidgets updated as well) - can you confirm that you no longer observe this issue? Thanks, Scott
Bug#1040688: wx3.2-examples: Some examples do not compile
On Sun, 9 Jul 2023, joel wrote: Package: wx3.2-examples Version: 3.2.2+dfsg-2 Severity: normal X-Debbugs-Cc: j.o.elpub...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Tried to compile examples to understand wx-config flags. * What exactly did you do (or not do) that was effective (or ineffective)? Installed a clean debian VM. Installed wx3.2-examples and the suggested libwxgtk3.2-dev + g++ and make Copied /usr/share/doc/wx3.2-examples/examples/samples to a writable dir. make # failed Iterate over each directory and make in each. Some are windows only and generate compile errors, but I have omitted those. * What was the outcome of this action? The following did not compile due to link errors: archive console ipc sockets -- eg: /usr/bin/ld: console_console.o: warning: relocation against `_ZTV17wxMDIClientWindow' in read-only section `.text._ZN17wxMDIClientWindowC2Ev[_ZN17wxMDIClientWindowC5Ev]' /usr/bin/ld: console_console.o: in function `wxWindowBase::GetBestVirtualSize() const': console.cpp:(.text._ZNK12wxWindowBase18GetBestVirtualSizeEv[_ZNK12wxWindowBase18GetBestVirtualSizeEv]+0x25): undefined reference to `wxWindowBase::GetBestSize() const' /usr/bin/ld: console_console.o: in function `wxWindowBase::CanBeFocused() const': Thanks for the bug report. I can confirm the issue. It looks like the console-based (ie, non-GUI) samples are mistakenly being compiled with GUI support, which fails at the link stage. I'll report this upstream. Thanks, Scott
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#996394: Patch available upstream
Control: tag -1 patch There's a patch available in a pull request upstream: https://github.com/CxxTest/cxxtest/pull/149/commits/2142549375e34b392f16e938fabf2c31951932bf Regards, Scott
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#1037927: ITP: fuse -- bazil.org/fuse - With macOS support and its own import path so replace directives aren't necessary
On Wed, 14 Jun 2023, Félix Sipma wrote: * Package name: fuse There's already a package named fuse in Debian: https://tracker.debian.org/pkg/fuse Regards, Scott
Bug#1037164: libwxgtk3.0-gtk3-0v5: wxwidgets not built with XTest support (libxtst6)
On Tue, 6 Jun 2023, Maxim Cournoyer wrote: I researched the problem and found that the feature I wanted was implemented using XTest, which is detected at wxWidgets' build time [1]. Looking at the Debian package dependencies, I found it did *not* depend on the libxtst6 package. I think it would be okay to enable xtest support even though it doesn't work under Wayland. However, this type of change doesn't seem appropriate for a stable release (it's possible it might even cause an ABI change), so we'd have to make it unstable after bookworm is released (this weekend?!). Thus, the bug should be reassigned to wxwidgets3.2. Scott
Bug#1034130: unblock: wxpython4.0/4.2.0+dfsg-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: wxpython...@packages.debian.org
Control: affects -1 + src:wxpython4.0
Please unblock package wxpython4.0
[ Reason ]
Remove reference to non-existent package (wx3.0-doc).
[ Impact ]
wxpython4.0 will get shipped with a Suggests for a non-existent package.
[ Tests ]
None.
[ Risks ]
Changes are trivial.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
None
unblock wxpython4.0/4.2.0+dfsg-3
diff -Nru wxpython4.0-4.2.0+dfsg/debian/changelog
wxpython4.0-4.2.0+dfsg/debian/changelog
--- wxpython4.0-4.2.0+dfsg/debian/changelog 2023-02-23 19:34:57.0
-0500
+++ wxpython4.0-4.2.0+dfsg/debian/changelog 2023-03-15 20:27:44.0
-0400
@@ -1,3 +1,9 @@
+wxpython4.0 (4.2.0+dfsg-3) unstable; urgency=medium
+
+ * d/control: update wx3.0-doc Suggests to wx3.2-doc (Closes: #1032867)
+
+ -- Scott Talbert Wed, 15 Mar 2023 20:27:44 -0400
+
wxpython4.0 (4.2.0+dfsg-2) unstable; urgency=medium
* d/control: make sip-tools requirements match python3-sipbuild
diff -Nru wxpython4.0-4.2.0+dfsg/debian/control
wxpython4.0-4.2.0+dfsg/debian/control
--- wxpython4.0-4.2.0+dfsg/debian/control 2023-02-23 19:26:38.0
-0500
+++ wxpython4.0-4.2.0+dfsg/debian/control 2023-03-15 20:26:03.0
-0400
@@ -33,7 +33,7 @@
Package: python3-wxgtk4.0
Architecture: any
Depends: python3-pil, python3-six, ${python3:Depends}, ${shlibs:Depends},
${misc:Depends}
-Suggests: wx3.0-doc
+Suggests: wx3.2-doc
Provides: ${python3:Provides}
Description: Python 3 interface to the wxWidgets Cross-platform C++ GUI toolkit
wxWidgets (formerly known as wxWindows) is a class library for C++ providing
Bug#1032585: RM: wxwidgets3.0 -- ROM; Unmaintained; replaced by wxwidgets3.2
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: wxwidgets...@packages.debian.org Control: affects -1 + src:wxwidgets3.0
Bug#1027015: fixed in wxwidgets3.2 3.2.1+dfsg-4
On Mon, 6 Mar 2023, Alec Leamas wrote: In file included from /usr/include/wx-3.2/wx/defs.h:550, from /usr/include/wx-3.2/wx/wxprec.h:12, from /home/mk/OpenCPN/OpenCPN/src/chartsymbols.cpp:27: /usr/include/wx-3.2/wx/matrix.h:44:1: error: expected identifier before ‘__attribute__’ 44 | WXDLLIMPEXP_CORE wxTransformMatrix: public wxObject | ^~~~ In file included from /home/mk/OpenCPN/OpenCPN/include/bbox.h:9, from /home/mk/OpenCPN/OpenCPN/include/s52s57.h:31, from /home/mk/OpenCPN/OpenCPN/include/s52plib.h:31, from /home/mk/OpenCPN/OpenCPN/include/chartsymbols.h:28, from /home/mk/OpenCPN/OpenCPN/src/chartsymbols.cpp:36: /usr/include/wx-3.2/wx/matrix.h:44:35: error: expected initializer before ‘:’ token 44 | WXDLLIMPEXP_CORE wxTransformMatrix: public wxObject Are you 100% positive that you're using the latest Debian package, and not an older package, or self-compiled wxWidgets? I ask because the error message above showing line 44 of matrix.h doesn't match line 44 in the latest Debian package. See here: https://sources.debian.org/src/wxwidgets3.2/3.2.2%2Bdfsg-2/include/wx/matrix.h/ Regards, Scott
Bug#1027917: wxwidgets3.2 FTCBFS: deliberately broken by upstream
On Mon, 20 Feb 2023, Helmut Grohne wrote: Hi Scott, On Mon, Feb 13, 2023 at 12:21:19PM -0500, Scott Talbert wrote: It seems that upstream has fixed this particular problem in the recent 3.2.2 release (and the crossqa checks seem to indicate further progress). I think "this particular problem" is fairly imprecise when the original report mentions two problems. The first of these was breaking pkg-config and this part indeed looks fixed to me. Although it seems there still might be further problems (on the packaging side?). The other problem about changed toolchain names persists and my understanding is that it is what makes the build fail. Yes, I sent that email before I had looked into the details and was overly optimistic about the upstream fix. Sorry, Scott
Bug#1027917: wxwidgets3.2 FTCBFS: deliberately broken by upstream
On Wed, 4 Jan 2023, Helmut Grohne wrote: Source: wxwidgets3.2 Version: 3.2.1+dfsg-4 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs Hi, wxwidgets3.2 fails to cross build from source, because it is deliberately broken by upstream on two accounts. I'm unsure how we can find a cooperative solution to this. The first aspect is that upstream doesn't trust pkg-config during cross building. They argue that it'll report wrong things. While that may be true in some environments, it is the thing that just works for Debian cross builds. Consequently, configure fails finding GTK and things don't get much better after that. The second aspect is that wx changes its toolchain name for cross compilation. That is, your build deliberately differs when it is natively built vs being cross built. Of course, this totally breaks Debian's approach to reproducible builds and also makes dh_install fail to locate relevant files (due to having been renamed). This latter aspect probably interacts with #875827. I guess that the actual issue is that wx assumes that if you want to cross build using wx, you should have a cross built wx. We don't do this distinction in Debian at all and believe that packages shouldn't differ between being cross built or natively built. So I'm offering a patch that makes wxwidgets3.2 cross build on Debian. It almost certainly is not upstreamable in the current form as it simply deletes the "breaking" changes. As much as this fixes Debian builds, applying it as is, will make other people unhappy and given #875827, toolchains cross built with this patch will not work for cross compilation (neither on Debian nor elsewhere). For the pkg-config, I think the best we can do is to add a configure switch such as --trust-pkg-config. While the current upstream behaviour is rather odd, I see how it may be useful rarely, though I'd rather pass PKG_CONFIG=false then. For the renaming the toolchain, more discussion is likely needed and the relevant upstream ticket https://github.com/wxWidgets/wxWidgets/issues/12698 doesn't seem to be doing much progress either. Hi Helmut, It seems that upstream has fixed this particular problem in the recent 3.2.2 release (and the crossqa checks seem to indicate further progress). Although it seems there still might be further problems (on the packaging side?). Regards, Scott
Bug#1031040: Build dependency on sip-tools too loose
On Fri, 10 Feb 2023, Simon Richter wrote: if I have a backport of sip6 available in a repo that is marked NotAutomatic: yes, and try to build wxpython there, the build dependencies will pull in sip-tools 5 and python3-sipbuild 6, which is inconsistent. Can you add the save version requirement to sip-tools to improve the chance to get a consistent set? We can, but it almost seems like this belongs in sip6 package. It really seems like sip-tools should require an exactly matched python3-sipbuild. I don't think upstream sip intended those to float independently. 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#1019416: transition: wxwidgets3.2
On Sat, 31 Dec 2022, Sebastian Ramacher wrote: Hi Scott On 2022-12-30 16:03:40 -0500, Scott Talbert wrote: On Fri, 9 Sep 2022, Sebastian Ramacher wrote: The tracker is at https://release.debian.org/transitions/html/wxwidgets-3.2.html. I have changed the is_good and is_bad to check for dependencies of the binary packges as .build-depends are not check for binary packages. Let me know if that misses anything. This tracker needs to be updated because of the other wxwidgets transition, I sent a merge request with what I think is required: https://salsa.debian.org/release-team/transition-data/-/merge_requests/35/diffs Merged, thanks. The only remaining package is libalien-wxwidgets-perl. From [1] I understand that updating it and libwx-perl is somewhat more involved. Are there any news? I've continued to make slow progress on it. I'll try to make a more concerted effort on it over the next week or two. Too much task switching in my Debian work. :) Happy New Year, Scott
Bug#1019416: transition: wxwidgets3.2
On Fri, 9 Sep 2022, Sebastian Ramacher wrote: The tracker is at https://release.debian.org/transitions/html/wxwidgets-3.2.html. I have changed the is_good and is_bad to check for dependencies of the binary packges as .build-depends are not check for binary packages. Let me know if that misses anything. This tracker needs to be updated because of the other wxwidgets transition, I sent a merge request with what I think is required: https://salsa.debian.org/release-team/transition-data/-/merge_requests/35/diffs Thanks, Scott
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#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#1026964: transition: wxwidgets3.2
On Tue, 27 Dec 2022, Scott Talbert wrote: On Tue, 27 Dec 2022, Sebastian Ramacher wrote: On 2022-12-27 08:59:19 -0500, Scott Talbert wrote: On Tue, 27 Dec 2022, Sebastian Ramacher wrote: Rebuild wxwidgets3.2 rdeps due to wxwidgets ABI change, due to rebuilding with GLX support instead of EGL support. See bug #1024147. Updated wxwidgets3.2 package has been uploaded to experimental. Please go ahead. Do I just re-upload to unstable now? Yes, and we will then schedule the rebuilds. Done, thanks! As best as I can tell, slic3r-prusa might have been missed in the binNMU list? Regards, Scott
Bug#1026964: transition: wxwidgets3.2
On Tue, 27 Dec 2022, Sebastian Ramacher wrote: On 2022-12-27 08:59:19 -0500, Scott Talbert wrote: On Tue, 27 Dec 2022, Sebastian Ramacher wrote: Rebuild wxwidgets3.2 rdeps due to wxwidgets ABI change, due to rebuilding with GLX support instead of EGL support. See bug #1024147. Updated wxwidgets3.2 package has been uploaded to experimental. Please go ahead. Do I just re-upload to unstable now? Yes, and we will then schedule the rebuilds. Done, thanks! Scott
Bug#1026964: transition: wxwidgets3.2
On Tue, 27 Dec 2022, Sebastian Ramacher wrote: Rebuild wxwidgets3.2 rdeps due to wxwidgets ABI change, due to rebuilding with GLX support instead of EGL support. See bug #1024147. Updated wxwidgets3.2 package has been uploaded to experimental. Please go ahead. Do I just re-upload to unstable now? Thanks, Scott
Bug#1026964: transition: wxwidgets3.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: wxwidgets...@packages.debian.org Control: affects -1 + src:wxwidgets3.2 Rebuild wxwidgets3.2 rdeps due to wxwidgets ABI change, due to rebuilding with GLX support instead of EGL support. See bug #1024147. Updated wxwidgets3.2 package has been uploaded to experimental. Ben file: title = "wxwidgets3.2"; is_affected = .depends ~ "libwxbase3.2-0" | .depends ~ "libwxgtk-media3.2-0" | .depends ~ "libwxgtk-webview3.2-0" | .depends ~ "libwxgtk3.2-0" | .depends ~ "libwxbase3.2-1" | .depends ~ "libwxgtk-media3.2-1" | .depends ~ "libwxgtk-webview3.2-1" | .depends ~ "libwxgtk3.2-1"; is_good = .depends ~ "libwxbase3.2-1" | .depends ~ "libwxgtk-media3.2-1" | .depends ~ "libwxgtk-webview3.2-1" | .depends ~ "libwxgtk3.2-1"; is_bad = .depends ~ "libwxbase3.2-0" | .depends ~ "libwxgtk-media3.2-0" | .depends ~ "libwxgtk-webview3.2-0" | .depends ~ "libwxgtk3.2-0";
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#1025335: ansible-core: autopkgtests need to depend on python3-pytest-forked
On December 2, 2022 2:54:19 PM EST, Lee Garrett wrote: >On 02/12/2022 19:15, Scott Talbert wrote: >> Source: ansible-core >> Version: 2.14.0-1 >> Severity: important >> >> ansible-core's autopkgtests need to add a Depends on python3-pytest-forked. >> >> python3-pytest-xdist used to depend on -forked, but it no longer does. >> >> See, for example: >> https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28872265/log.gz > >Thanks! Will update it in the next release. Also, ansible needs to same update. If you could make these updates in the relatively short term it would be appreciated. pytest-xdist can't migrate otherwise. Thanks, 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#1025335: ansible-core: autopkgtests need to depend on python3-pytest-forked
Source: ansible-core Version: 2.14.0-1 Severity: important ansible-core's autopkgtests need to add a Depends on python3-pytest-forked. python3-pytest-xdist used to depend on -forked, but it no longer does. See, for example: https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28872265/log.gz
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#1024147: Please build with --disable-glcanvasegl
On Tue, 15 Nov 2022, Yuri D'Elia wrote: Package: libwxgtk3.2-0 Version: 3.2.1+dfsg-1 Severity: normal wxWidgets 3.1+ enables EGL support by default, which also needs to be enabled in GLEW. GLEW 2.2.0 EGL support is disabled (see #1020640 for bug in glew 2.2). This results a failure in creating an opengl context in several programs: see https://github.com/supermerill/SuperSlicer/issues/1093#issuecomment-1046004099 for one example. I'm not sure whether would be the best course of action (ie: patching glew or disabling EGL canvas support in wx). I'm currently rebuilding wx with --disable-glcanvasegl in order to fix this issue. I agree, my plan is to rebuild wxWidgets with --disable-glcanvasegl. Unfortunately, this results in an ABI change, so I'm trying to sort out with the release team how they'd prefer to do this. Thanks, Scott
Bug#1020640: libglew2.2: Glew built without, wxwidgets with EGL support
On Sat, 5 Nov 2022, Andreas Metzler wrote: On 2022-10-03 Alastair McKinstry wrote: As maintainer would be open to changing Glew to EGL support, but need to understand better the consequences. [...] Mandriva also enables glew egl but pulls a patchset from glew GIT head https://github.com/OpenMandrivaAssociation/glew/tree/master and indeed if I build glew GIT head (egl build, i.e. SYSTEM=linux-egl) and run hugin against it it just works and does not crash. Thanks Andreas for your work testing out glew with EGL support. I'm coming to the realization, though, that wxWidgets EGL-only wxGLCanvas may not be ready for prime time, given this challenge and several other bugs (slic3r-prusa, pronterface, etc). Thus, I'm leaning towards rebuilding wxWidgets with GLX support (and adding back our force-X11 so things don't break on Wayland patch). The one challenge with this is that it will break ABI and thus will require rebuilding all packages that link with the libwx-gl library. Any comments or concerns? Thanks, Scott
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#1023634: RM: objcryst-fox [mips64el] -- ROM; cctbx unavailable on mips64el
Package: ftp.debian.org Severity: normal
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#1023428: RM: objcryst-fox [armel armhf i386 mips64el mipsel] -- ROM; cctbx unavailable on 32-bit
Package: ftp.debian.org Severity: normal
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#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#794821: libwxbase3.0-0: segmentation fault (SIGSEGV) with gnuplot5
On Fri, 21 Oct 2022, Vincent Lefevre wrote: Control: reassign -1 libwxbase3.0-0v5 3.0.5.1+dfsg-5 as the bug still occurs. On 2019-10-10 08:21:22 +1300, Olly Betts wrote: Hmm, I don't seem to get a core file (and sadly am struggling to work out how to enable them on current Debian). But repeating that after installing these packages (assuming unstable) would be more enlightening: libwxbase3.0-0v5-dbgsym libwxgtk3.0-gtk3-0v5-dbgsym Here's the backtrace: As of yesterday, gnuplot has been rebuilt using wxWidgets 3.2. Can you please try again with gnuplot 5.4.4+dfsg1-2 and see if the crash still exists? Thanks, Scott
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#1019801: xmlcopyeditor: Please transition to wxwidgets3.2
reopen -1 found -1 1.3.0.0-1 severity -1 important thanks Resent to not -maintonly.
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#1019806: Patch for sooperlooper & wxWidgets 3.2
Merge request sent: https://salsa.debian.org/multimedia-team/sooperlooper/-/merge_requests/1 Regards, Scott
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#1019787: silverjuke: Please transition to wxwidgets3.2
On Thu, 15 Sep 2022, Dr. Tobias Quathamer wrote: Am 14.09.22 um 21:42 schrieb s...@techie.net: Hi, Please transition silverjuke from wxwidgets3.0 to wxwidgets3.2. [...] Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already). Hi Scott, thanks for the information. Currently, the build fails with wxwidgets3.2 due to this error: 'const class wxHtmlTag' has no member named 'GetBeginPos'; did you mean 'GetBeginIter'? The file in question is src/sjbase/skinml.cpp, line 885[1]. Could you help me with a patch or a hint what to do here? Patch sent: https://salsa.debian.org/debian/silverjuke/-/merge_requests/1 Regards, Scott
Bug#1019809: gentle: Please transition to wxwidgets3.2
On Thu, 15 Sep 2022, Andreas Tille wrote: Control: tags -1 help Am Wed, Sep 14, 2022 at 03:42:14PM -0400 schrieb s...@techie.net: Please transition gentle from wxwidgets3.0 to wxwidgets3.2. I would like to support this but I have no idea about wxwidgets. For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Unfortunately this is not enouth in this case. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already). I've tagged the bug help and hope you can commit the patches needed. Merge request with patch: https://salsa.debian.org/med-team/gentle/-/merge_requests/1 Regards, Scott
Bug#1019811: treeviewx: Please transition to wxwidgets3.2
On Thu, 15 Sep 2022, Andreas Tille wrote: Control: tags -1 help Am Wed, Sep 14, 2022 at 03:42:14PM -0400 schrieb s...@techie.net: Please transition gentle from wxwidgets3.0 to wxwidgets3.2. I would like to support this but I have no idea about wxwidgets. For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Unfortunately this is not enouth in this case. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already). I've tagged the bug help and hope you can commit the patches needed. Here is the link to Salsa CI https://salsa.debian.org/med-team/treeviewx/-/jobs/3238712 Merge request with patch: https://salsa.debian.org/med-team/treeviewx/-/merge_requests/2 Regards, Scott
Bug#1019764: ctsim: Please transition to wxwidgets3.2
On Thu, 15 Sep 2022, Andreas Tille wrote: Control: tags -1 help Am Wed, Sep 14, 2022 at 03:42:14PM -0400 schrieb s...@techie.net: Please transition gentle from wxwidgets3.0 to wxwidgets3.2. I would like to support this but I have no idea about wxwidgets. For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Unfortunately this is not enouth in this case. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already). I've tagged the bug help and hope you can commit the patches needed. Here you can find the compile issues in Salsa CI https://salsa.debian.org/med-team/ctsim/-/jobs/3238687 Here you go: https://salsa.debian.org/med-team/ctsim/-/merge_requests/1 Scott
Bug#1019841: amule: Please transition to wxwidgets3.2
On Wed, 14 Sep 2022, Sandro Tosi wrote: control: forwarded -1 https://github.com/amule-project/amule/issues/340 Hello Scott, For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already). it looks like an attempt was made in fedora to build amule with 3.2 and quickly reverted (i dont know the details, just what's in the git repo), see the links in the gh issue (which i think you may want to subscribe to, if you have a user on gh). would you be able to have a look at amule and wxwidgets3.2 compatibility? It seems amule isn't in Fedora proper - it's in RPMFusion, which is why I didn't see it in my repoquery. I seem to recall amule is some sort of P2P client, which I'd rather not try to connect to. Can you try the changes in this pull request? A few users seem to report success with those. https://github.com/amule-project/amule/pull/168 Thanks, Scott
Bug#1019416: transition: wxwidgets3.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition It would be good if we could eliminate wxwidgets3.0 from the archive for bullseye - the last upstream release (3.0.5.1) was over 2 years ago, and there's very little upstream interest in bugs in it now. Manually tracking packages is somewhat error prone, and in particular misses people adding new dependencies on wx3.0, so I'd like to make use of the transition tracker to automatically track which packages still need attention. This transition probably doesn't need allocating a "slot" to happen at this point, since packages can mostly be updated to use wxwidgets3.2 independently of one another. Ben file: title = "wxwidgets3.2"; is_affected = .build-depends ~ /libwx(gtk(-media|-webview)?)3\.2-dev|wx3\.2-(headers|i18n)/ | .build-depends ~ /libwx(base|gtk(-media|-webview)?)3\.0(-gtk3)?-dev|wx3\.0-(headers|i18n)/; is_good = .build-depends ~ /libwx(gtk(-media|-webview)?)3\.2-dev|wx3\.2-(headers|i18n)/; is_bad = .build-depends ~ /libwx(base|gtk(-media|-webview)?)3\.0(-gtk3)?-dev|wx3\.0-(headers|i18n)/; Thanks, Scott
Bug#919903: ITP: wxwidgets3.2 -- wxWidgets Cross-platform C++ GUI toolkit
On 2022-08-27 03:20, Andrea Pappacoda wrote: Control: tags -1 - wontfix Hi, I've just built wxwidgets3.2 from the salsa [repo], but it seems that the wx-common package isn't being built. Is this intentional? Yes, because wx-common is currently being built by wxwidgets3.0 until we get wxwidgets3.2 through NEW and into the archive. I needed wxWidgets 3.2 because I'm packaging Cemu (#1018037), and it requires the latest wxWidgets version. Also, why was this packaged in a new repo? Because I wanted to get rid of some cruft from the old repo and also switch to a git-buildpackage layout. Scott
Bug#1016650: haskell-devscripts: Support internal libraries
Package: haskell-devscripts Severity: important haskell-devscripts does not currently support packages with internal libraries (correctly). Partial support was added to support GHC registration with a directory of files instead of a single file, where the first file in the directory was selected, but this unfortunately was too naive and does not work in all cases. Packages currently have to be patched to remove the internal libraries (e.g., attoparsec), so ideally we should add proper support for internal libraries to the tooling.
Bug#1016649: haskell-devscripts: haddock recipe run on all architectures
Package: haskell-devscripts Severity: important The haddock recipe is being run on all arches, when it really only needs to be run once on the -all arch. This is not only wasteful, but it causes problems for certain packages (e.g., haskell-gi-gtk) where the documentation cannot be built on mips without running out of memory. This is a regression from the pre-Perl state.
Bug#1016354: debhelper: provide a way to set environment variables with Dh_Lib qx_cmd()
Package: debhelper Version: 13.8 Severity: wishlist It would be very useful to have a variant of Dh_Lib's qx_cmd() that allows setting environment variables (or a version of doit() that allows capturing the output).
