[Freewx-maint] Start building GTK+3 packages

[Scott Talbert]

On Mon, 5 Mar 2018, Olly Betts wrote:

>> My hope would be that we could have only wx3.0 with GTK3 in buster. However,
>> if we have to keep wx3.0 with GTK2 as well, I don't think that would be the
>> end of the world.  Even though upstream seems to be moving closer to a
>> release, I think there's too much uncertainty with wx3.2 to try to make any
>> plans based on it.
>>
>> So, thus I think the recommendation would be: use wx3.0 GTK3 unless it
>> causes problems for your app.  And if we can get all of the users, off GTK2,
>> great, then we can remove it.
>
> OK, so once this is in place, we should start to gently nudge
> maintainers towards it, then review progress nearer buster.

Yes, agreed.

> Are you thinking to just provide wxpython built against the GTK3
> variant?

Yes, that's what I was thinking.  And maybe even migrate everyone to 
wxpython4.0 and we could retire 3.0, but that may be wishful thinking.  I 
do know some upstreams are working on this already though.

>>> I don't currently have a salsa login set up so can't directly comment
>>> on the patch, but not sure why you configure GTK3 with:
>>>
>>>> +    --cache-file=/dev/null \
>>
>> Hmm, I thought they created accounts for all DD's.  It does look like you
>> have an account: https://salsa.debian.org/olly
>
> But I don't have a password for it, so it's not usefully "set up" yet.
> I've not have a chance to read the salsa docs yet - perhaps I just need
> to do a password reset.

Yes, it sounds like you just need to do a password reset to get access to 
your account.

> I guess the idea is to put the cache where it's not removed by
> "debian/rules clean" so that when testing stuff outside of a chroot
> builder you get a faster rerun of configure.
>
> If that's actually a useful gain, perhaps it's worth having a
> "config_cache_gtk3" or something.  Or we could just scrap passing
> --cache-file at all and simplify debian/rules.  Using ccache provides a
> speed-up to configure that probably isn't quite as good but persists
> between runs better and can benefit chroot builds with a suitable setup.
>
> I don't know what others do, but since we split out wxpython the build
> time for wxwidgets packages with a modern machine in a chroot is short
> enough that I've not personally felt the need to fiddle around outside
> one.
>
> Anyway, overriding it to /dev/null for GTK3 seems OK if we actually
> understand why it's needed - I was just concerned that the need to do so
> indicated a deeper problem somewhere.

Yes, I generally only do builds with sbuild myself, so I would be okay 
with just removing the cache if you think that's better.

Scott