[Freewx-maint] Start building GTK+3 packages
swt at techie.net
Mon Mar 5 15:24:14 UTC 2018
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.
> Are you thinking to just provide wxpython built against the GTK3
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
> 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
> 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.
More information about the Freewx-maint