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#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
Re: Accepted wxwidgets3.2 3.2.2+dfsg-1 (source) into unstable
On Mon, 13 Feb 2023, gregor herrmann wrote: On Mon, 13 Feb 2023 00:09:20 +0100, Cyril Brulebois wrote: Debian FTP Masters (2023-02-11): Format: 1.8 Date: Sat, 11 Feb 2023 13:15:16 -0500 Source: wxwidgets3.2 Architecture: source Version: 3.2.2+dfsg-1 Distribution: unstable Urgency: medium Maintainer: wxWidgets Maintainers Changed-By: Scott Talbert Closes: 1028427 Changes: wxwidgets3.2 (3.2.2+dfsg-1) unstable; urgency=medium . * d/watch: fix download URL when using GitHub API * Update to new upstream release 3.2.2 * Add Breaks/Replaces to libwxgtk-gl3.2-1 (Closes: #1028427) This seems to have made libalien-wxwidgets-perl uninstallable, as seen in my devel chroot but also for any systems, as mentioned on tracker: https://tracker.debian.org/pkg/wxwidgets3.2 If we're lucky, a binNMU of libalien-wxwidgets-perl against libwxgtk3.2-dev,libwxgtk-media3.2-dev 3.2.2 (and later of libwx-perl against the rebuilt libalien-wxwidgets-perl) might be enough. A local rebuild of libalien-wxwidgets-perl runs through, including autopkgtests. (I haven't tried the second step with libwx-perl.) Sorry about that - I didn't realize that libalien-wxwidgets-perl had a dependency on an exact wxWidgets version (this is probably unnecessary; just a major.minor one is probably sufficient - that's what wxPython has). Yes, a binNMU of libalien-wxwidgets-perl should fix it. Sorry, Scott
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#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";
Re: Help with resolving an issue with wxwidgets3.2
On Fri, 23 Dec 2022, Sebastian Ramacher wrote: Hi Scott On 2022-12-12 22:10:51 -0500, Scott Talbert wrote: On Mon, 12 Dec 2022, Sam Hartman wrote: "Scott" == Scott Talbert writes: Scott> Would Option 1, which was "Rebuild wxWidgets and then binNMU Scott> all packages that link with libwx_gtk3u_gl library (about a Scott> dozen packages)." be acceptable? We could also add Scott> appropriate "Breaks" to the library package containing the gl Scott> library. There are times in the past (I'm thinking c++ abi transitions) wher.e we've changed the name of the shlibs package but not of the soname. So you end up overriding lintian because your shlib package does not match the soname exactly. You need to update your symbols or shlibs files to depend on the new shlibs package name. It complicates the Debian packaging a bit, and you probably end up carrying the complexity, but you don't need to diverge from soname, and if you change build options in the future you may need to do it again. Would an option like this work for both sides? Yes, that's originally what I planned to do, but Olly suggested that changing the shlib package name without changing the library soname might be against policy? This approach would be okay with me, though. As an aside, wx's shlib package names already don't match the soname exactly. (Not sure of the history there, but they either never have, or haven't for a long time.) In this case, changing the package name should be enough. I'd treat it similar to the v5 "transitions" that we had to do with GCC 5 and C++ libraries. What's the status? Time is running short. Uploaded to experimental just now. Will need to clear NEW, though, due to binary package name changes. Thanks, Scott
Re: Help with resolving an issue with wxwidgets3.2
On Mon, 12 Dec 2022, Sam Hartman wrote: "Scott" == Scott Talbert writes: Scott> Would Option 1, which was "Rebuild wxWidgets and then binNMU Scott> all packages that link with libwx_gtk3u_gl library (about a Scott> dozen packages)." be acceptable? We could also add Scott> appropriate "Breaks" to the library package containing the gl Scott> library. There are times in the past (I'm thinking c++ abi transitions) wher.e we've changed the name of the shlibs package but not of the soname. So you end up overriding lintian because your shlib package does not match the soname exactly. You need to update your symbols or shlibs files to depend on the new shlibs package name. It complicates the Debian packaging a bit, and you probably end up carrying the complexity, but you don't need to diverge from soname, and if you change build options in the future you may need to do it again. Would an option like this work for both sides? Yes, that's originally what I planned to do, but Olly suggested that changing the shlib package name without changing the library soname might be against policy? This approach would be okay with me, though. As an aside, wx's shlib package names already don't match the soname exactly. (Not sure of the history there, but they either never have, or haven't for a long time.) Thanks, Scott
Re: Help with resolving an issue with wxwidgets3.2
On Fri, 25 Nov 2022, Graham Inggs wrote: Hi Scott On Wed, 16 Nov 2022 at 04:03, Scott Talbert wrote: 2) Rebuild wxWidgets with soname bump and then rebuild all packages that use wx (about 67 packages). What do you think is the best way to proceed? Option 2 seems the safest. Please upload to experimental and request another transition slot. Hello again, How firm are you on wanting us to proceed with Option 2 for this? The big downside to this is that we would have to maintain a downstream soname version essentially forever. Aside from this diversion from upstream, we'd have to rely on a upstream's unmaintained and Python 2-only build tool, Bakefile. Would Option 1, which was "Rebuild wxWidgets and then binNMU all packages that link with libwx_gtk3u_gl library (about a dozen packages)." be acceptable? We could also add appropriate "Breaks" to the library package containing the gl library. Thanks, Scott
Re: Help understanding why a package isn't migrating
On Sun, 27 Nov 2022, Sebastian Ramacher wrote: On 2022-11-24 09:47:51 -0500, Scott Talbert wrote: On Thu, 24 Nov 2022, Sebastian Ramacher wrote: Hi Scott On 2022-11-23 19:38:26 +0100, Paul Gevers wrote: Hi Scott, On 23-11-2022 15:26, Scott Talbert wrote: Hi Release Team, I'm trying to understand why this package (haskell-copilot-theorem[1]) isn't migrating to testing. It looks like it is saying that it is being blocked by haskell-what4, but haskell-what4 has already migrated to testing on October 17. Also, if I look at excuses for haskell-what4, there aren't any. The only thing I can possibly think is that it is referring to migration of binNMU's, but I can't see any way to see the status of those. Is it possible? Thanks, Scott [1] https://qa.debian.org/excuses.php?package=haskell-copilot-theorem It says: haskell-copilot-theorem haskell-parameterized-utils/ppc64el (not considered) Which means that haskell-copilot-theorem on ppc64el depends on src:haskell-parameterized-utils. Picking one of the binaries from that source and asking rmadison says: paul@mulciber ~ $ rmadison libghc-parameterized-utils-dev libghc-parameterized-utils-dev | 2.1.5.0-2+b1 | testing| amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libghc-parameterized-utils-dev | 2.1.5.0-2+b2 | unstable | mips64el, mipsel, ppc64el libghc-parameterized-utils-dev | 2.1.5.0-2+b3 | unstable | armhf, i386, s390x libghc-parameterized-utils-dev | 2.1.5.0-2+b4 | unstable | amd64, arm64, armel So indeed, the binNMU's of that source are out-of-sync between testing and unstable. Searching in the excuses [2] I see this: Depends: haskell-parameterized-utils/amd64 haskell-th-abstraction So that points at haskell-th-abstraction (which seems in a similar situation but then with haskell-clash-prelude) And if you go down the rabbit hole far enough, you'll eventually reach #1023149 which needs to be taken care of. Yes, that's the same conclusion I came to. Thanks! The next blocker is #1023020. Is there a next blocker that you're aware of? Thanks, Scott
Re: Help understanding why a package isn't migrating
On Thu, 24 Nov 2022, Sebastian Ramacher wrote: Hi Scott On 2022-11-23 19:38:26 +0100, Paul Gevers wrote: Hi Scott, On 23-11-2022 15:26, Scott Talbert wrote: Hi Release Team, I'm trying to understand why this package (haskell-copilot-theorem[1]) isn't migrating to testing. It looks like it is saying that it is being blocked by haskell-what4, but haskell-what4 has already migrated to testing on October 17. Also, if I look at excuses for haskell-what4, there aren't any. The only thing I can possibly think is that it is referring to migration of binNMU's, but I can't see any way to see the status of those. Is it possible? Thanks, Scott [1] https://qa.debian.org/excuses.php?package=haskell-copilot-theorem It says: haskell-copilot-theorem haskell-parameterized-utils/ppc64el (not considered) Which means that haskell-copilot-theorem on ppc64el depends on src:haskell-parameterized-utils. Picking one of the binaries from that source and asking rmadison says: paul@mulciber ~ $ rmadison libghc-parameterized-utils-dev libghc-parameterized-utils-dev | 2.1.5.0-2+b1 | testing| amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libghc-parameterized-utils-dev | 2.1.5.0-2+b2 | unstable | mips64el, mipsel, ppc64el libghc-parameterized-utils-dev | 2.1.5.0-2+b3 | unstable | armhf, i386, s390x libghc-parameterized-utils-dev | 2.1.5.0-2+b4 | unstable | amd64, arm64, armel So indeed, the binNMU's of that source are out-of-sync between testing and unstable. Searching in the excuses [2] I see this: Depends: haskell-parameterized-utils/amd64 haskell-th-abstraction So that points at haskell-th-abstraction (which seems in a similar situation but then with haskell-clash-prelude) And if you go down the rabbit hole far enough, you'll eventually reach #1023149 which needs to be taken care of. Yes, that's the same conclusion I came to. Thanks! Scott
Help understanding why a package isn't migrating
Hi Release Team, I'm trying to understand why this package (haskell-copilot-theorem[1]) isn't migrating to testing. It looks like it is saying that it is being blocked by haskell-what4, but haskell-what4 has already migrated to testing on October 17. Also, if I look at excuses for haskell-what4, there aren't any. The only thing I can possibly think is that it is referring to migration of binNMU's, but I can't see any way to see the status of those. Is it possible? Thanks, Scott [1] https://qa.debian.org/excuses.php?package=haskell-copilot-theorem
Help with resolving an issue with wxwidgets3.2
Hi Release Team, In order to resolve an issue with wxWidgets 3.2 and packages that use wxWidgets OpenGL support (wxGLCanvas), I need to rebuild wxWidgets with GLX support instead of EGL support, as unfortunately, most of the companion OpenGL packages (e.g., glew, pyglet) are not ready for EGL support (for example, hugin uses wxWidgets[EGL] and glew[GLX] for its OpenGL support -> which currently fails, see bug #1020640). Unfortunately, rebuilding wxWidgets with GLX instead of EGL support results in an ABI change for the libwx_gtk3u_gl library. Thus, I can see two ways to resolve this: 1) Rebuild wxWidgets and then binNMU all packages that link with libwx_gtk3u_gl library (about a dozen packages). 2) Rebuild wxWidgets with soname bump and then rebuild all packages that use wx (about 67 packages). What do you think is the best way to proceed? 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#960522: nmu: libwx-perl_1:0.9932-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu libwx-perl_1:0.9932-5 . ANY . unstable . -m "Rebuild for new wxwidgets3.0 3.0.5.1+dfsg release" -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#960364: nmu: libalien-wxwidgets-perl_0.69+dfsg-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu libalien-wxwidgets-perl_0.69+dfsg-3 . ANY . unstable . -m "Rebuild for new wxwidgets3.0 3.0.5.1+dfsg release" -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#894663: transition: wxwidgets3.0
On Mon, 16 Sep 2019, Gunter Königsmann wrote: I can try to bisect wxWidgets. But as building wxWidgets drains my battery in minutes I will be able to do at maximum one step per week. You can only charge your battery once a week? If you're really strapped for compile resources, you can probably use some of the debian porter boxes? Scott
Bug#894663: transition: wxwidgets3.0
On Mon, 16 Sep 2019, Gunter Königsmann wrote: * Scroll Wheels and Two-Finger scroll are broken in this combination, if Wayland is used (934386) and Is two finger scrolling really a high priority issue? It seems like a nice to have rather than a must-have IMHO. * If a horizontal scrollbar is visible all custom controls (e.G. wxMaxima's worksheet) flicker badly (934386) On this issue, I'm not convinced that upstream can reproduce it, based on the comments in the ticket. I don't think that I've reproduced it either. Since you claim that it doesn't occur with wx 3.1, can you do a bisection between wx 3.0 and 3.1 to determine which commit fixed it? If we can figure that out, we can backport the patches. Vadim (who is one of the maintainers) can reproduce it. I cannot guarantee, though, if the right graphics card/GTK version/something else needs to be used in order to trigger the bug. Or if this is one of the esoteric bugs that only affect a handful of users. You are right, he did say that. He also said he didn't know if he would have time in the near future to look into it. So, what you say about trying to bisect the issue? If wxMaxima otherwise would be dropped from debian I am willing to switch to a flickering version that uses GTK3. But if I don't occur this risk I would rather stay at GTK3 until wxGTK 3.2 is released - which will fix this issue. The wxWidgets maintainers told me that wxGTK 3.2 will be released "soon". But the same was true a year ago - which I normally would be fine with: wxGTK 3.1 works fine, the combination of wxGTK 3.0 and GTK2 works fine, too - and it is wise to release a library when it is ready, not according to an arbitrary schedule. Well, there is still time to fix the issues - Bullseye release is still a long way off. And yes, upstream wx claims that wx 3.2 will be "soon" but we have heard that for a long time. :) So I don't think we can depend on that. That only partially answers my question. Currently I am playing with the thought if the right idea would be uploading a wxMaxima version that uses GTK3 to debian testing and looking if anyone except Vadim and me is affected by the bug. Well, the only thing we can control is that the GTK2 build of wx will be gone in Bullseye, barring any unforseen circumstances. Whether that will be with wx 3.0 or wx 3.2, remains to be seen. Scott
Bug#894663: transition: wxwidgets3.0
On Sat, 14 Sep 2019, Gunter Königsmann wrote: * Scroll Wheels and Two-Finger scroll are broken in this combination, if Wayland is used (934386) and Is two finger scrolling really a high priority issue? It seems like a nice to have rather than a must-have IMHO. * If a horizontal scrollbar is visible all custom controls (e.G. wxMaxima's worksheet) flicker badly (934386) On this issue, I'm not convinced that upstream can reproduce it, based on the comments in the ticket. I don't think that I've reproduced it either. Since you claim that it doesn't occur with wx 3.1, can you do a bisection between wx 3.0 and 3.1 to determine which commit fixed it? If we can figure that out, we can backport the patches. If wxMaxima otherwise would be dropped from debian I am willing to switch to a flickering version that uses GTK3. But if I don't occur this risk I would rather stay at GTK3 until wxGTK 3.2 is released - which will fix this issue. The wxWidgets maintainers told me that wxGTK 3.2 will be released "soon". But the same was true a year ago - which I normally would be fine with: wxGTK 3.1 works fine, the combination of wxGTK 3.0 and GTK2 works fine, too - and it is wise to release a library when it is ready, not according to an arbitrary schedule. Well, there is still time to fix the issues - Bullseye release is still a long way off. And yes, upstream wx claims that wx 3.2 will be "soon" but we have heard that for a long time. :) So I don't think we can depend on that. Scott
Bug#926286: unblock: wxpython4.0/4.0.4+dfsg-2
Control: tags -1 - moreinfo On Wed, 3 Apr 2019, Paul Gevers wrote: There were two causes of FTBFS with SIP 4.19.14 that are fixed in my pending upload: 1) Addition of SIP_OVERRIDE 2) Addition of a mapped type for size_t The rollback of SIP_OVERRIDE in the sip4 package technically removes the need for the SIP_OVERRIDE FTFBS fixes in wxpython4.0, but my preference would be to leave them in because they appear to be fix actual bugs, even though they are no longer FTBFS bugs. Do you have any opinion on that? Ok, so there remains a FTBFS problem. Then yes, please proceed with uploading your fix, remove the moreinfo tag and we will check again. Are the patches known upstream? The build (wxpython4.0/4.0.4+dfsg-2) is now in unstable. The patches have been submitted upstream, but they are not all merged. Some background info on the patches, of which there are three: Patch 1 is submitted as pull request upstream. It is not yet merged. Patch 2 is not submitted upstream because it wouldn't be merged until upstream officially switches its build to SIP 4.19.14. It's a trivial patch anyway. Patch 3 is actually to the wxWidgets (the C++ library that wxPython wraps) public interface headers. This has been submitted to wxWidgets upstream and merged. Thanks, Scott
Bug#926286: unblock: wxpython4.0/4.0.4+dfsg-2
On Wed, 3 Apr 2019, Paul Gevers wrote: Please unblock package wxpython4.0 This fixes a wxpython4.0 FTBFS bug (#924856) with SIP 4.19.14 which was uploaded in late February. Instead, we (well, Dmitry) fixed sip4 to not add the new sip_override. Do you still want your new package in buster? If so, please make sure the package is actually in unstable. Currently there is nothing to unblock. (I didn't actually review your changes, so don't rush the upload if the FTBFS is actually fixed now. My bad. I'm new to unblock requests. My read of the guidelines was that I needed to get the unblock approval before uploading to unstable. There were two causes of FTBFS with SIP 4.19.14 that are fixed in my pending upload: 1) Addition of SIP_OVERRIDE 2) Addition of a mapped type for size_t The rollback of SIP_OVERRIDE in the sip4 package technically removes the need for the SIP_OVERRIDE FTFBS fixes in wxpython4.0, but my preference would be to leave them in because they appear to be fix actual bugs, even though they are no longer FTBFS bugs. Do you have any opinion on that? Thanks, Scott
Bug#926286: Debdiff
diff -Nru wxpython4.0-4.0.4+dfsg/debian/changelog
wxpython4.0-4.0.4+dfsg/debian/changelog
--- wxpython4.0-4.0.4+dfsg/debian/changelog 2019-01-25 18:19:15.0
-0500
+++ wxpython4.0-4.0.4+dfsg/debian/changelog 2019-04-01 22:41:28.0
-0400
@@ -1,3 +1,9 @@
+wxpython4.0 (4.0.4+dfsg-2) unstable; urgency=medium
+
+ * d/patches: Fix FTBFS with SIP 4.19.14 (Closes: #924856)
+
+ -- Scott Talbert Mon, 01 Apr 2019 22:41:28 -0400
+
wxpython4.0 (4.0.4+dfsg-1) unstable; urgency=medium
* Update d/copyright and d/watch to use uscan repack mechanism vs. repack.sh
diff -Nru wxpython4.0-4.0.4+dfsg/debian/patches/fix-build-sip-4.19.14-1.patch
wxpython4.0-4.0.4+dfsg/debian/patches/fix-build-sip-4.19.14-1.patch
--- wxpython4.0-4.0.4+dfsg/debian/patches/fix-build-sip-4.19.14-1.patch
1969-12-31 19:00:00.0 -0500
+++ wxpython4.0-4.0.4+dfsg/debian/patches/fix-build-sip-4.19.14-1.patch
2019-03-23 12:14:47.0 -0400
@@ -0,0 +1,132 @@
+From 3636ba3e606e3080942427beb68528f11cfb408e Mon Sep 17 00:00:00 2001
+From: Scott Talbert
+Date: Fri, 22 Mar 2019 23:17:31 -0400
+Subject: [PATCH 1/2] Fix building with SIP 4.19.14
+
+This commit fixes building Phoenix with SIP 4.19.14. One of the main changes
+in this release was to add SIP_OVERRIDE, which adds the C++ override keyword
+to method declarations that are intended to override the C++ class that SIP
+is wrapping. Unfortunately, this exposed a few bugs which caused compile
+errors. Most of the fixes are to the interface headers. The two trickier
+fixes were to wxFileConfig and wxRendererNative.
+
+For wxFileConfig, the Save method's second parameter, 'conv', had been ignored.
+This caused the override check to fail. This was resolved by ignoring the
+auto-generated Save() and adding a manually generated one without the second
+parameter.
+
+For wxRendererNative, the DrawTitleBarBitmap method is actually pure virtual
+in the subclass, so the fix was to ignore it there. In the subclass
+wxDelegateRendererNative, it is concrete, but only on certain platforms. This
+was fixed in a similar way by adding a manually generated method that will
+do the right thing on the platforms that support it.
+
+There is one other fix required for SIP 4.19.14: SIP has now added its own
+wrapper for size_t, so it required removing the one in wacky_ints. This change
+was omitted for now because it should probably wait until Phoenix officially
+moves to 4.19.14.
+---
+ etg/config.py | 10 +-
+ etg/printfw.py | 1 -
+ etg/renderer.py | 18 +++---
+ etg/statbox.py | 2 +-
+ ext/wxWidgets | 2 +-
+ 5 files changed, 22 insertions(+), 11 deletions(-)
+
+diff --git a/etg/config.py b/etg/config.py
+index 8675e751..299f63b2 100644
+--- a/etg/config.py
b/etg/config.py
+@@ -179,7 +179,7 @@ def run():
+ c.find('wxFileConfig').findOverload('wxInputStream').find('conv').ignore()
+ ctor =
c.find('wxFileConfig').findOverload('wxString').find('conv').ignore()
+ #ctor.items.remove(ctor.find('conv'))
+-ctor = c.find('Save').find('conv').ignore()
++c.find('Save').ignore()
+ c.find('GetGlobalFile').ignore()
+ c.find('GetLocalFile').ignore()
+
+@@ -188,6 +188,14 @@ def run():
+ c.find('GetFirstEntry').ignore()
+ c.find('GetNextEntry').ignore()
+
++c.addCppMethod('bool', 'Save', '(wxOutputStream& os)',
doc=c.find('Save').briefDoc, body="""\
++#if wxUSE_STREAMS
++return self->Save(*os);
++#else
++wxPyRaiseNotImplemented();
++#endif
++""")
++
+
+
+ #-
+diff --git a/etg/printfw.py b/etg/printfw.py
+index 0d0500ff..90f5f75a 100644
+--- a/etg/printfw.py
b/etg/printfw.py
+@@ -61,7 +61,6 @@ def run():
+ c.find('CreateCanvas').isVirtual = True
+ c.find('CreateControlBar').isVirtual = True
+ c.find('Initialize').isVirtual = True
+-c.find('InitializeWithModality').isVirtual = True
+
+
+
+diff --git a/etg/renderer.py b/etg/renderer.py
+index 2319b62d..eea14676 100644
+--- a/etg/renderer.py
b/etg/renderer.py
+@@ -43,25 +43,29 @@ def run():
+ c.find('GetGeneric').mustHaveApp()
+ c.find('GetDefault').mustHaveApp()
+ c.find('Set').mustHaveApp()
++c.find('DrawTitleBarBitmap').ignore()
++draw_tb_bmp_doc = c.find('DrawTitleBarBitmap').briefDoc
++
++
++c = module.find('wxDelegateRendererNative')
++c.mustHaveApp()
++c.addPrivateCopyCtor()
+
+
+ #virtual void DrawTitleBarBitmap(wxWindow *win,
+ #wxDC& dc,
+ #const wxRect& rect,
+ #wxTitleBarButton button,
+-#int flags = 0) = 0;
+-c.find('DrawTitleBarBitmap').setCppCode("""\
++#int flags = 0);
++c.addCppMethod('void', 'DrawTitleBarBitmap', '(wx
Bug#926286: unblock: wxpython4.0/4.0.4+dfsg-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package wxpython4.0 This fixes a wxpython4.0 FTBFS bug (#924856) with SIP 4.19.14 which was uploaded in late February. unblock wxpython4.0/4.0.4+dfsg-2 -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#858670: nmu: wxpython3.0_3.0.2.0+dfsg-3
On Sat, 25 Mar 2017, Adam D. Barratt wrote: wxwidgets3.0 was recently binNMU'd in stretch. wxpython3.0 needs to be rebuilt to avoid a C++ ABI mismatch warning when all wxPython applications are used. It was binNMUed _in unstable_, a month ago. If there's an issue, why wasn't it noticed earlier? I wasn't aware of the fact that wxWidgets was binNMUed until someone reported a problem, as there isn't any sort of notification. In fact, I can't even find a bug report that requested one. More specifically, I can only see one binNMU for wxpython3.0 having been performed in the past, in 2015. If the packages are so tightly coupled, shouldn't there have been far more frequent rebuilds in the past? (and how did the combination of wxwidgets3.0 uploaded on 2016-07-29 and wxpython3.0 uploaded on 2016-07-19 work?) The coupling is really only related to C++ ABI changes. As long as the C++ ABI hasn't change, there isn't any problem. nmu wxpython3.0_3.0.2.0+dfsg-3 . ANY . stretch . -m "Rebuild due to wxWidgets C++ ABI change" That won't work, in any case - unstable and testing have the same binary version of the packages, so the binNMUs would have to be performed in unstable and then migrate (as testing can't have a higher version of the package than unstable). My bad, I'm relatively unfamiliar with the binNMU process. So it should be: nmu wxpython3.0_3.0.2.0+dfsg-3 . ANY . unstable . -m "Rebuild due to wxWidgets C++ ABI change" Does it then automatically migrate to testing, or does an unblock have to be filed?
Bug#858670: nmu: wxpython3.0_3.0.2.0+dfsg-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, wxwidgets3.0 was recently binNMU'd in stretch. wxpython3.0 needs to be rebuilt to avoid a C++ ABI mismatch warning when all wxPython applications are used. nmu wxpython3.0_3.0.2.0+dfsg-3 . ANY . stretch . -m "Rebuild due to wxWidgets C++ ABI change" -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
