Re: Proposed MBF: wxwidgets3.2 transition
On 2022-09-15 Scott Talbert wrote: > On Thu, 15 Sep 2022, Andreas Metzler wrote: [...] > > A successful build is no guarantee for a working packaging though. e.g. > > hugin errs out immediately when built with the newer wxWidgets. > That is certainly true - and probably another good reason we don't use the > single-dev-package approach. > Do you want help with those errors? Hello Scott, thanks for the offer, upstream has been uite helpful. However something else came up: | After starting up, klicking on [Preview | Panorama (OpenGL)] yields an error (and nothing else: | | -- | Error initializing GLEW | Fast preview window cannot be opened. | -- | with this message on the console: | ERROR: 14:13:49.978869 (./src/hugin1/hugin/GLViewer.cpp:133) SetUpContext(): Error initialising GLEW: Unknown error. | | Klicking on [Preview Panorama (OpenGL)] again succeeds. Upstream pointed me to hugin documentation which says: Note: On Linux wxWidgets 3.1.5 and later is by default compiled with EGL support for the wxGLCanvas class. In this case you need to activate EGL support explicitly also in GLEW, otherwise there are crashes when intializing the wxGLCanvas. Afaict from looking at Debian's glew 2.2.0 it is indeed built without EGL support (debian/rules does not use SYSTEM=...-egl). cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Proposed MBF: wxwidgets3.2 transition
On Wed, 14 Sep 2022 16:00:32 -0400, Scott Talbert wrote: > > libalien-wxwidgets-perl (.69+dfsg-4 uploaded to experimental. > > > > Next step: check what libwx-perl [0] says and do a binNMU or sourceful > > upload (it needs to switch from wxperl-gtk-3-0-5-uni-gcc-3-4 to > > wxperl-gtk-3-2-0-uni-gcc-3-4). > > > > Reviews of the packaging changes welcome. > > Thanks! Looks fine, other than a Build-Depends on wx-common isn't necessary > - libwxgtk3.2-dev will pull that in. Thanks for the review and the email! I noticed that wx-common gets pulled in, I just thought that it's "cleaner" to have an explicit build dependency on wx-common as we are using wx-config. But if this is an internal implementation detail of the wx* packages and we can be sure that we always get wx-config when we install libwxgtk*-dev I'm happy to remove the build dependency. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: Proposed MBF: wxwidgets3.2 transition
On Thu, 15 Sep 2022, Andreas Metzler wrote: On 2022-09-13 Scott Talbert wrote: Hi, wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release. 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). [...] A successful build is no guarantee for a working packaging though. e.g. hugin errs out immediately when built with the newer wxWidgets. That is certainly true - and probably another good reason we don't use the single-dev-package approach. Do you want help with those errors? Scott
Re: Proposed MBF: wxwidgets3.2 transition
On 2022-09-13 Scott Talbert wrote: > Hi, > wxWidgets 3.2 (a new API/ABI stable release) has been released a few months > ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped > supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx > package users to wxwidgets3.2 for bullseye, with the plan to remove > wxwidgets3.0 before release. > 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). [...] A successful build is no guarantee for a working packaging though. e.g. hugin errs out immediately when built with the newer wxWidgets. cu Andreas
Re: Proposed MBF: wxwidgets3.2 transition
On Wed, 14 Sep 2022, gregor herrmann wrote: On Mon, 12 Sep 2022 22:32:23 -0400, Scott Talbert wrote: wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. … For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. … Debian Perl Group libalien-wxwidgets-perl libalien-wxwidgets-perl (.69+dfsg-4 uploaded to experimental. Next step: check what libwx-perl [0] says and do a binNMU or sourceful upload (it needs to switch from wxperl-gtk-3-0-5-uni-gcc-3-4 to wxperl-gtk-3-2-0-uni-gcc-3-4). Reviews of the packaging changes welcome. Thanks! Looks fine, other than a Build-Depends on wx-common isn't necessary - libwxgtk3.2-dev will pull that in. Scott
Re: Proposed MBF: wxwidgets3.2 transition
On Mon, 12 Sep 2022 22:32:23 -0400, Scott Talbert wrote: > wxWidgets 3.2 (a new API/ABI stable release) has been released a few months > ago and is now packaged in unstable as wxwidgets3.2. … > For most packages, the transition should be as simple as changing > Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. … > Debian Perl Group >libalien-wxwidgets-perl libalien-wxwidgets-perl (.69+dfsg-4 uploaded to experimental. Next step: check what libwx-perl [0] says and do a binNMU or sourceful upload (it needs to switch from wxperl-gtk-3-0-5-uni-gcc-3-4 to wxperl-gtk-3-2-0-uni-gcc-3-4). Reviews of the packaging changes welcome. Cheers, gregor [0] and maybe libwx-scintilla-perl as well -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: Proposed MBF: wxwidgets3.2 transition
On Tue, 13 Sep 2022, Simon McVittie wrote:
For most libraries, the deciding factor would be: are library users
expected to find the library via a single pkg-config file that cannot
coexist with the other version (like libpng's libpng.pc and OpenSSL's
libssl.pc/libcrypto.pc/openssl.pc), or do they ship versioned pkg-config
files that can coexist (like GTK 2/3/4, Qt 4/5/6 and SDL 1/2)?
A more technology-neutral way to ask this question is: when the library
user names the library that they want, do they do so with a
major-version-qualified name, or with an unversioned name?
For libraries like GTK and SDL, the answer is that they normally use a
major-version-qualified name: Autotools PKG_CHECK_MODULES([GTK], [gtk+-3.0]),
Meson dependency('gtk4'), CMake find_package(SDL2 REQUIRED) or similar.
Because names are interfaces and interfaces are names, we package these
libraries with correspondingly versioned names: libgtk-3-dev, libgtk-4-dev,
libsdl2-dev and so on.
For libraries like libpng and OpenSSL, the answer is that they normally
use a non-versioned name: Autotools PKG_CHECK_MODULES([openssl]) or Meson
dependency('libpng') or similar. We package these libraries with unversioned
names: libssl-dev, libpng-dev and so on.
I think following that principle would make me lean towards a -dev package
without the major version, because library users seem to ask for it with
dependency('wxwidgets', modules: ['core']) or WX_CONFIG_CHECK([3.0])
or $(wx-config --cflags --libs core) or something like that - where the
3.0 is a minimum version, rather than a major version to select.
The answer is somewhere in between. wxWidgets major releases are designed
to coexist with each other. The library user can select a specific version,
by using the version-specific wx-config (e.g., wx-config-3.0 or
wx-config-3.2), or using the generic wx-config with
wx-config --version=x.y.
In any event, I don't plan to change the packaging design at this point
(it's been this way forever, AFAIK). Maybe when wx 3.4 comes out in ~10
years we can reconsider. :)
Scott
Re: Proposed MBF: wxwidgets3.2 transition
On Tue, 13 Sep 2022 at 19:55:01 +0100, Simon McVittie wrote:
> For most libraries, the deciding factor would be: are library users
> expected to find the library via a single pkg-config file that cannot
> coexist with the other version (like libpng's libpng.pc and OpenSSL's
> libssl.pc/libcrypto.pc/openssl.pc), or do they ship versioned pkg-config
> files that can coexist (like GTK 2/3/4, Qt 4/5/6 and SDL 1/2)?
A more technology-neutral way to ask this question is: when the library
user names the library that they want, do they do so with a
major-version-qualified name, or with an unversioned name?
For libraries like GTK and SDL, the answer is that they normally use a
major-version-qualified name: Autotools PKG_CHECK_MODULES([GTK], [gtk+-3.0]),
Meson dependency('gtk4'), CMake find_package(SDL2 REQUIRED) or similar.
Because names are interfaces and interfaces are names, we package these
libraries with correspondingly versioned names: libgtk-3-dev, libgtk-4-dev,
libsdl2-dev and so on.
For libraries like libpng and OpenSSL, the answer is that they normally
use a non-versioned name: Autotools PKG_CHECK_MODULES([openssl]) or Meson
dependency('libpng') or similar. We package these libraries with unversioned
names: libssl-dev, libpng-dev and so on.
I think following that principle would make me lean towards a -dev package
without the major version, because library users seem to ask for it with
dependency('wxwidgets', modules: ['core']) or WX_CONFIG_CHECK([3.0])
or $(wx-config --cflags --libs core) or something like that - where the
3.0 is a minimum version, rather than a major version to select.
smcv
Re: Proposed MBF: wxwidgets3.2 transition
On Tue, 13 Sep 2022 at 13:52:11 -0400, Scott Talbert wrote: > Major wxWidgets releases are not API compatible, so there will be packages > that will require changes (although there are not many > backwards-incompatible API changes between 3.0 and 3.2). I would think of > it more akin to GTK-2 vs GTK-3, although there are not as many API changes. > Historically, there have been larger API changes between releases (e.g., 2.8 > to 3.0). > > I suppose it would be technically possible to do it with a single -dev > package, but that would lead to potentially extended breakages of unstable > while the packages that require changes get updated. For most libraries, the deciding factor would be: are library users expected to find the library via a single pkg-config file that cannot coexist with the other version (like libpng's libpng.pc and OpenSSL's libssl.pc/libcrypto.pc/openssl.pc), or do they ship versioned pkg-config files that can coexist (like GTK 2/3/4, Qt 4/5/6 and SDL 1/2)? If the former, then we'd normally expect to see a single -dev package like libpng-dev and libssl-dev; if the latter, then a -dev package per major version (whatever "major" might mean in this context), like libgtk-3-dev and libgtk-4-dev, preferably co-installable on the same system. wxWidgets doesn't seem to have a .pc file at all (?) and the 3.0 and 3.2 versions seem to share wx-config(1) and wxwin.m4 in wx-common (?), so I'm not sure quite how that fits together, and whether it's more like the OpenSSL case or the GTK case. smcv
Re: Proposed MBF: wxwidgets3.2 transition
On Tue, 13 Sep 2022, Mattia Rizzolo wrote: On Mon, Sep 12, 2022 at 10:32:23PM -0400, Scott Talbert wrote: wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release. 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). Question from somebody who doesn't know wxWidgets: if the update from one release to the other is so simple (at least, you make it sound very simple, and #1019416 has no blocking bugs, so I reckon everything works?) then why is this not packaged like pretty much any other library with an unversionde source package and an unversioned -dev binary package? Major wxWidgets releases are not API compatible, so there will be packages that will require changes (although there are not many backwards-incompatible API changes between 3.0 and 3.2). I would think of it more akin to GTK-2 vs GTK-3, although there are not as many API changes. Historically, there have been larger API changes between releases (e.g., 2.8 to 3.0). I suppose it would be technically possible to do it with a single -dev package, but that would lead to potentially extended breakages of unstable while the packages that require changes get updated. Scott
Re: Proposed MBF: wxwidgets3.2 transition
On Mon, Sep 12, 2022 at 10:32:23PM -0400, Scott Talbert wrote: > wxWidgets 3.2 (a new API/ABI stable release) has been released a few months > ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped > supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx > package users to wxwidgets3.2 for bullseye, with the plan to remove > wxwidgets3.0 before release. > > 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). Question from somebody who doesn't know wxWidgets: if the update from one release to the other is so simple (at least, you make it sound very simple, and #1019416 has no blocking bugs, so I reckon everything works?) then why is this not packaged like pretty much any other library with an unversionde source package and an unversioned -dev binary package? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Proposed MBF: wxwidgets3.2 transition
Hi, wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release. 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). The Release Team has set up a transition tracker for us to track progress [1]. I'm planning to file bugs for all packages that haven't yet migrated. dd-list is attached. Please let me know if you have any questions or comments. Thanks, Scott [1] https://release.debian.org/transitions/html/wxwidgets-3.2.htmlA. Maitland Bottoms freedv (U) Alastair McKinstry mathgl (U) Alec Leamas opencpn wxsvg (U) Alessio Treglia sooperlooper (U) Alexander Wirt icinga2 (U) Andreas Bombe cubicsdr (U) limesuite (U) Andreas Metzler hugin (U) Andreas Rönnquist poedit (U) Andreas Tille ctsim (U) gentle (U) lamarc (U) treeviewx (U) Andrej Shadura wxhexeditor Andrius Merkys openbabel (U) Aniol Marti aegisub Anton Gladky gnuplot (U) Axel Beckert gnudatalanguage (U) Barak A. Pearlmutter ucblogo Barry deFreese asc (U) plee-the-bear (U) Bartosz Fenski asc (U) Bas Couwenberg grass (U) spatialite-gui (U) Bas Wijnen openmsx-catapult Benjamin Drung audacity (U) Brandon Barnes dolphin-emu (U) Bruno Kleinert scorched3d (U) Carlo Segre fityk (U) objcryst-fox Carsten Schoenert kicad (U) Cesar Mauri eviacam Charles Plessy treeviewx (U) Chow Loong Jin mediainfo slic3r-prusa (U) Christoph Berg cubicsdr (U) limesuite (U) trustedqsl (U) Christoph Schmidt-Hieber stimfit D Haley 3depict (U) Damyan Ivanov flamerobin libalien-wxwidgets-perl (U) Daniel Echeverry tintii Daniel Leidert openbabel (U) David Hart 4pane David Henningsson audacity (U) David Paleino codeblocks spatialite-gui (U) David Prévot codeblocks (U) Debian 3-D Printing Packages <3dprinter-gene...@lists.alioth.debian.org> slic3r-prusa Debian Accessibility Team espeakedit Debian Astronomy Team gnudatalanguage munipack Debian Electronics Team kicad Debian Erlang Packagers erlang Debian Games Team 0ad asc darkradiant dolphin-emu megaglest openyahtzee pcsx2 plee-the-bear scorched3d scummvm-tools springlobby Debian GIS Project grass saga spatialite-gui Debian Hamradio Maintainers cubicsdr ebook2cwgui freedv limesuite trustedqsl Debian l10n developers poedit Debian Med Packaging Team ctsim gentle lamarc mriconvert treeviewx Debian Multimedia Maintainers audacity sooperlooper wxsvg Debian Nagios Maintainer Group icinga2 Debian Perl Group libalien-wxwidgets-perl Debian PhotoTools Maintainers hugin Debian QA Group codelite Debian Science Maintainers 3depict bossa cba fityk mathgl xylib Debian Science Team gnuplot plplot wxastrocapture Debichem Team openbabel qutemol Dennis Braun audacity (U) sooperlooper (U) Dimitrios Eftaxiopoulos mathgl (U) Dmitry Smirnov freespace2-launcher-wxlauncher Dominique Dumont libalien-wxwidgets-perl (U) Dr. Tobias Quathamer silverjuke Ferdinand Griffon cba (U) Filip Hroch munipack (U) Francesco Paolo Lovergine grass (U) saga (U) Free Ekanayaka audacity (U) Georges Khaznadar kicad (U) Gianfranco Costamagna poedit (U) Gonéri Le Bouder plee-the-bear (U) Graham Inggs qutemol (U) gregor herrmann libalien-wxwidgets-perl (U) Gunter Königsmann wxmaxima Gürkan Myczko gnudatalanguage (U) Gürkan Myczko drs4eb James Cowgill dolphin-emu (U) Jan Wagner icinga2 (U) JaromÃr MikeÅ¡ audacity (U) sooperlooper (U) Johan Van de Wauw saga (U) Jose G. López pgn2web Jose Luis Blanco Claraco mrpt Julien Jorge plee-the-bear (U) Jussi Pakkanen meson Kamal Mostafa ebook2cwgui (U) Kartik Mistry xchm Kevin M. Rosenberg ctsim (U) Laszlo Boszormenyi (GCS) wxsqlite3 Ludovic Rousseau 0ad (U) Mark Vejvoda megaglest (U) Markus Frosch icinga2 (U) Markus Koschany asc (U) megaglest (U) openyahtzee (U) springlobby (U) Martin Budaj therion Michael Banck openbabel (U) qutemol (U) Miguel A. Colón Vélez pcsx2 (U) Miriam Ruiz xmlcopyeditor Morten Kjeldgaard qutemol (U) NIIBE Yutaka golly Ole Streicher gnudatalanguage (U) plplot (U) Olly Betts libalien-wxwidgets-perl (U)
