Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Fri, Oct 25, 2019 at 09:27:48AM +1300, Olly Betts wrote:
> On Tue, Oct 22, 2019 at 08:58:42AM +1300, Olly Betts wrote:
> > * mrpt was updated but the build failed on mipsel due to running out of
> >   memory and it's now entangled in auto-opencv.  But it's due for AUTORM
> >   on 2019-10-28 so that should resolve itself within a week.
> 
> No change here.

The AUTORM happened for mrpt.

> However, checking with "dak rm" on coccia, I discovered four packages
> which build-depend on libwxgtk3.0-dev but without a resulting runtime
> dependency.  I've filed bugs against these and set them as blocking this
> bug.  They should at least be easy to address.

Fixes for these extra four have now been uploaded and checking again:

olly@coccia:~$ dak rm -Rn -b libwxgtk3.0-dev
[...]
# Broken Depends:
wxsvg: libwxsvg-dev
wxwidgets3.0: libwxgtk-media3.0-dev

# Broken Build-Depends:
amule: libwxgtk3.0-dev
codeblocks: libwxgtk3.0-dev
cubicsdr: libwxgtk3.0-dev
objcryst-fox: libwxgtk3.0-dev
pcsx2: libwxgtk3.0-dev
sooperlooper: libwxgtk3.0-dev
treesheets: libwxgtk3.0-dev
ucblogo: libwxgtk3.0-dev
wxsvg: libwxgtk3.0-dev

Which is just the packages which are only in unstable, so aren't
blockers.

The codeblocks maintainers never responded, but taffit is preparing an
update to the latest upstream release so that at least should be off the
list fairly soon.

I've uploaded wxwidgets3.0 dropping the GTK2 flavour packages, so I
think we can consider this transition complete.  I'll leave actually
closing this bug to someone on the release team in case I've missed
something.

Upstream wx are making noises about actually releasing 3.2 early next
year, so we may have another wx transition before bullseye.  We've
managed to prune many of the rdeps which are inactive upstream and
unmaintained in Debian, so the next one should hopefully be less work.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Tue, Oct 22, 2019 at 08:58:42AM +1300, Olly Betts wrote:
> * mrpt was updated but the build failed on mipsel due to running out of
>   memory and it's now entangled in auto-opencv.  But it's due for AUTORM
>   on 2019-10-28 so that should resolve itself within a week.

No change here.

> * codelite is orphaned and needs a new upstream version, but one of the
>   upstream developers has prepared an update which is currently in the
>   process of being sponsored.

This has been uploaded and has built on all release archs.

> * filezilla seems to be immune to AUTORM (presumably due to its popcon
>   score).  The maintainer appears to have prepared an upload 3.5 weeks
>   ago but not uploaded it:

This has been uploaded and has built on all release archs.

However, checking with "dak rm" on coccia, I discovered four packages
which build-depend on libwxgtk3.0-dev but without a resulting runtime
dependency.  I've filed bugs against these and set them as blocking this
bug.  They should at least be easy to address.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Wed, Aug 07, 2019 at 08:29:50AM +1200, Olly Betts wrote:
> Now that we're post-release, Scott Talbert has filed bugs and the
> transition is progressing well (we've gone from 17% to 41% in just
> a week).

We're now at 94% with only 3 packages left:

* mrpt was updated but the build failed on mipsel due to running out of
  memory and it's now entangled in auto-opencv.  But it's due for AUTORM
  on 2019-10-28 so that should resolve itself within a week.

* codelite is orphaned and needs a new upstream version, but one of the
  upstream developers has prepared an update which is currently in the
  process of being sponsored.  If that doesn't happen, AUTORM is
  2019-10-30.

* filezilla seems to be immune to AUTORM (presumably due to its popcon
  score).  The maintainer appears to have prepared an upload 3.5 weeks
  ago but not uploaded it:
  https://qa.debian.org/cgi-bin/vcswatch?package=filezilla
  I have nudged them via #933416 and offered to sponsor it.  If there's
  no response I'll just upload it (it's already within the dev-ref rules
  for NMUing).  I've already checked what's in the VCS builds OK in
  current unstable.

So one way or another everything should be resolved by the end of this
month.  We can then upload wxwidgets3.0 dropping the GTK2 packages.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Tue, Sep 17, 2019 at 05:26:00PM +0200, Gunter Königsmann wrote:
> Making separate bug reports for that, too, and bisecting them costs more
> time than I currently have at hand. Which is why I asked if we
> absolutely need to switch to GTK3.

There's no *absolute* need, but it's unlikely wxmaxima would be in
bullseye if you insisted on sticking with GTK2.

But as Scott already said, there's time before bullseye to work through
remaining problems - that's why we started the transition early and
why we're trying to push it along now.  Please put your time and energy
into resolving any blockers rather than into questioning the transition.

The only potential fly in the ointment is that upstream are making
noises about 3.2.0 again - *if* a release actually happens and in time
for us to seriously consider it for bullseye then we'd really want to
get this transition done first.

Either way, the key thing is to provide upstream with clear bug reports
(and all the information in one place, not split over an upstream bug
report, a debian bug report, and a thread on an upstream mailing list
without even any links between any of them) and ideally their preferred
form of reproducer.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Gunter Königsmann]

On 16.09.19 22:50, Scott Talbert wrote:
> 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?

Not once a week, but as I have other projects, as well, I am very
limited on time on unlimited power.

>
> If you're really strapped for compile resources, you can probably use
> some of the debian porter boxes?
>
Wow... ...will look into that possibility. Before that I will have to
find a way to ship around other bugs of the combination wxWidgets/GTK3,
though, that make it hard to see if the  "scroll" sample, if it would
work, would flicker (see
https://www.peterpall.de/wxMaxima/debian/FlickerScreenshot1.png).

Making separate bug reports for that, too, and bisecting them costs more
time than I currently have at hand. Which is why I asked if we
absolutely need to switch to GTK3.

Kind regards,

   Gunter.

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Mon, Sep 16, 2019 at 09:25:54AM -0400, Scott Talbert wrote:
> On Mon, 16 Sep 2019, Gunter Königsmann wrote:
> > 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.

Note you don't upload to testing - you upload to unstable, and then
the package migrates to testing.

I think this is probably a good idea.  It seems there's something system
dependent here since wxmaxima rebuilt to use GTK3 doesn't seem to
flicker when scrolling horizontally or vertically to me, and so allowing
easy wider testing would be helpful in trying to work out what's going
on.

> 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.

At this point the wxwidgets3.0-gtk3 transition is reporting 54% done:

https://release.debian.org/transitions/

There's also one bug tagged "pending" and two packages uploaded to
"experimental", so effectively 57% if you include stuff that's in
progress (there are about 100 packages involved in all).

I think even if wx 3.2 does come out soon we'd really want to get the
current transition completed first.  Having to deal with 3 wx variants
at once sounds like more pain than necessary, and if we get the
GTK2->GTK3 issues dealt with now then that's less to deal with in the
second transition.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Scott Talbert]

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

[Gunter Königsmann]

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.

Kind regards,

  Gunter.

On 14.09.19 21:31, Scott Talbert wrote:
> 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#894663: transition: wxwidgets3.0

[Scott Talbert]

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

[Gunter Königsmann]

On 14.09.19 21:31, Scott Talbert wrote:
> 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.
>
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.

>> 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.

Kind regards,

   Gunter.

Bug#894663: transition: wxwidgets3.0

[Scott Talbert]

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#894663: transition: wxwidgets3.0

[Gunter Königsmann]

Dear all,

If I interpreted the last mail I got right transition to GTK3 is now
deemed "important".

Unfortunately wxMaxima is only barely usable if the combination wxgtk3.0
and GTK3 is used:

  * Scroll Wheels and Two-Finger scroll are broken in this combination,
if Wayland is used (934386
) and
  * If a horizontal scrollbar is visible all custom controls (e.G.
wxMaxima's worksheet) flicker badly (934386
)

I assume these bugs limit the usability of other applications, as well,
but might not be visible in the first tests after packaging; On the
application's side even with the help of the wxWidgets community I
failed to find a workaround:

  * If you manually enable double-buffering of wxMaxima's worksheet
instead of letting wxWidgets decide if the compositor already
provides double-buffering the worksheet goes completely blank.
  * If you disable double-buffering it flickers.
  * If you let wxWidgets decide if double-buffering is necessary it
flickers, as well.
  * If you try to do a manual double-buffering: You render the visible
part of the worksheet into a bitmap and then blit the bitmap into
the window the bitmap is correctly generated and contains the given
worksheet portion. But blitting the bitmap into the output window
results in a black window.

Hence not having to much debian experience my question is: "How
important is important?"

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.

Kind regards,

   Gunter.

Bug#894663: transition: wxwidgets3.0

[Emilio Pozuelo Monfort]

On 06/08/2019 22:29, Olly Betts wrote:
> On Sun, Sep 30, 2018 at 10:09:28AM +0100, Olly Betts wrote:
>> On Sun, Sep 30, 2018 at 08:47:00AM +, Niels Thykier wrote:
>>> Are we planning to complete this transition
>>> in buster (transition deadline being 2019-01-05) or it is fine if this
>>> transition is first completed in bullseye ?
>>
>> I'd still love to complete it for buster, but I suspect we may well not
>> manage to get all the remaining rdeps moved over.
>>
>> We never actually got around to filing bugs against rdeps, but perhaps
>> we should to encourage them to move where there aren't any blockers.
> 
> Now that we're post-release, Scott Talbert has filed bugs and the
> transition is progressing well (we've gone from 17% to 41% in just
> a week).
> 
> Please can you re-enable export for this transition so that it appears
> in tracker.d.o, etc?  I've attached a patch which should be suitable.

ftr, as discussed on irc, export is disabled so that the PTS doesn't ask
maintainers to avoid uploads of these packages.

Cheers,
Emilio

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Sun, Sep 30, 2018 at 10:09:28AM +0100, Olly Betts wrote:
> On Sun, Sep 30, 2018 at 08:47:00AM +, Niels Thykier wrote:
> > Are we planning to complete this transition
> > in buster (transition deadline being 2019-01-05) or it is fine if this
> > transition is first completed in bullseye ?
> 
> I'd still love to complete it for buster, but I suspect we may well not
> manage to get all the remaining rdeps moved over.
> 
> We never actually got around to filing bugs against rdeps, but perhaps
> we should to encourage them to move where there aren't any blockers.

Now that we're post-release, Scott Talbert has filed bugs and the
transition is progressing well (we've gone from 17% to 41% in just
a week).

Please can you re-enable export for this transition so that it appears
in tracker.d.o, etc?  I've attached a patch which should be suitable.

Cheers,
Olly
diff --git a/config/ongoing/wxwidgets3.0-gtk3.ben b/config/ongoing/wxwidgets3.0-gtk3.ben
index 27a9e072..525b0a4f 100644
--- a/config/ongoing/wxwidgets3.0-gtk3.ben
+++ b/config/ongoing/wxwidgets3.0-gtk3.ben
@@ -3,4 +3,3 @@ is_affected = .depends ~ /libwxgtk(-media)?3\.0-0v5/ | .depends ~ /libwxgtk(-med
 is_good = .depends ~ /libwxgtk(-media)?3\.0-gtk3-0v5/;
 is_bad = .depends ~ /libwxgtk(-media)?3\.0-0v5/;
 notes = "#894663";
-export = false;

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Sun, Sep 30, 2018 at 08:47:00AM +, Niels Thykier wrote:
> What is the status on this?

Less progress than I'd like.  Partly that's down to my not finding the
time to push this along, but there are also two bugs which affect the
GTK3 wx build but not the GTK2 one:

OpenGL support doesn't work under wayland unless you force GTK3 to use
X11 (#904753) - GTK2 doesn't support wayland, so essentially is always
forcing X11 here.

There's a coordinate overflow issue (#906060) which looks like it is
probably not in wx itself, but in cairo or some other layer.  The GTK2
build doesn't use those layers.

The first can be worked around, but I don't think there's a known way
to work around the second.

> Are we planning to complete this transition
> in buster (transition deadline being 2019-01-05) or it is fine if this
> transition is first completed in bullseye ?

I'd still love to complete it for buster, but I suspect we may well not
manage to get all the remaining rdeps moved over.

We never actually got around to filing bugs against rdeps, but perhaps
we should to encourage them to move where there aren't any blockers.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Niels Thykier]

Emilio Pozuelo Monfort:
> Control: forwarded -1 
> https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html
> Control: tags -1 confirmed
> 
> On 03/04/18 04:59, Olly Betts wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> There are now packages with a GTK3 build of wxwidgets3.0, and these have
>> just migrated to testing.  We'd like to start to encourage dependent
>> packages to switch to this instead of the GTK2 build.
>>
>> The GTK2 and GTK3 flavours coexist so dependent packages can move
>> over individually and we don't need a transition slot, but it would be
>> useful to have a transition tracker set up to help track progress.
> 
> Sounds good. Tracker added.
> 
>> The procedure for updating these is to update the BDs to use the
>> wxgtk*3.0-gtk3-dev package(s) instead of wxgtk*3.0-dev, check that the
>> package still builds OK, and then check that the result works OK.
> 
> I suppose at some point you'll file bugs so rdeps migrate faster?
> 
> Cheers,
> Emilio
> 

Hi Olly,

What is the status on this?  Are we planning to complete this transition
in buster (transition deadline being 2019-01-05) or it is fine if this
transition is first completed in bullseye ?

Thanks,
~Niels

Processed: Re: Bug#894663: transition: wxwidgets3.0

[Debian Bug Tracking System]

Processing control commands:

> forwarded -1 
> https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html
Bug #894663 [release.debian.org] transition: wxwidgets3.0
Set Bug forwarded-to-address to 
'https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html'.
> tags -1 confirmed
Bug #894663 [release.debian.org] transition: wxwidgets3.0
Added tag(s) confirmed.

-- 
894663: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894663
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#894663: transition: wxwidgets3.0

[Emilio Pozuelo Monfort]

Control: forwarded -1 
https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html
Control: tags -1 confirmed

On 03/04/18 04:59, Olly Betts wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> There are now packages with a GTK3 build of wxwidgets3.0, and these have
> just migrated to testing.  We'd like to start to encourage dependent
> packages to switch to this instead of the GTK2 build.
> 
> The GTK2 and GTK3 flavours coexist so dependent packages can move
> over individually and we don't need a transition slot, but it would be
> useful to have a transition tracker set up to help track progress.

Sounds good. Tracker added.

> The procedure for updating these is to update the BDs to use the
> wxgtk*3.0-gtk3-dev package(s) instead of wxgtk*3.0-dev, check that the
> package still builds OK, and then check that the result works OK.

I suppose at some point you'll file bugs so rdeps migrate faster?

Cheers,
Emilio

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

There are now packages with a GTK3 build of wxwidgets3.0, and these have
just migrated to testing.  We'd like to start to encourage dependent
packages to switch to this instead of the GTK2 build.

The GTK2 and GTK3 flavours coexist so dependent packages can move
over individually and we don't need a transition slot, but it would be
useful to have a transition tracker set up to help track progress.

We've already switched a few source packages.  The list of remaining
affected source packages is:

0ad
3depict
4pane
aegisub
amule
audacity
bochs
bossa
cba
chipw
codeblocks
codelite
ctsim
cubicsdr
darkradiant
delaboratory
dolphin-emu
ebook2cwgui
erlang
espeakedit
eviacam
filezilla
fityk
flamerobin
freedink-dfarc
freedv
freespace2-launcher-wxlauncher/contrib
fwknop-gui
gentle
ginkgocadx
gnudatalanguage
gnuplot
golly
gspiceui
hugin
icinga2
jugglemaster
kicad
lamarc
libwx-glcanvas-perl
libwx-perl
libwx-scintilla-perl
limesuite
maitreya
mathgl
mediainfo
megaglest
mriconvert
mrpt
munipack
objcryst-fox
openbabel
openmsx-catapult
openyahtzee
passwordsafe
pcsx2
pgadmin3
pgn2web
plee-the-bear
plplot
poedit
qutemol
rapidsvn
saga
sandboxgamemaker/contrib
scorched3d
scummvm-tools
silverjuke
sitplus
slic3r-prusa
sooperlooper
spatialite-gui
spek
springlobby
stimfit
stx-btree
thuban
tintii
treesheets
treeviewx
trustedqsl
ucblogo
usbprog
wxastrocapture
wxhexeditor
wxmaxima
wxsqlite3
xchm
xmlcopyeditor

The procedure for updating these is to update the BDs to use the
wxgtk*3.0-gtk3-dev package(s) instead of wxgtk*3.0-dev, check that the
package still builds OK, and then check that the result works OK.

(There's also wxpython3.0 which has already been switched but is waiting
to clear binary-NEW.)

Cheers,
Olly

Ben file:

title = "wxwidgets3.0";
is_affected = .depends ~ "libwxgtk(-media)?3\.0-0v5" | .depends ~ 
"libwxgtk(-media)?3\.0-gtk3-0v5";
is_good = .depends ~ "libwxgtk(-media)?3\.0-gtk3-0v5";
is_bad = .depends ~ "libwxgtk(-media)?3\.0-0v5";


signature.asc
Description: PGP signature