[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2014-04-20 6:41:35
Message-ID: 400C2DB1-9B60-491D-A4FC-3FAE5FEE0D82 () gmail ! com
[Download RAW message or body]

On 19/04/2014, at 7:52 PM, Thomas Lübking wrote:
> Am Samstag, 19. April 2014 schrieb Ian Wadham :
> > On 18/04/2014, at 4:58 AM, Thomas Lübking wrote:
> 
> > > If removing the KLocale() constructor avoids it, i'm fairly sure it will be the \
> > > bogus CFStringGetLength call, so to me it would seem more reasonable to protect \
> > > convert_CFString_to_QString 
> > > kdelibs/kdecore/kernel/kkernel_mac.cpp
> > > -----------
> > > 
> > > QString convert_CFString_to_QString(CFStringRef str) {
> > > +    if (str == NULL) {
> > > +        return QString();
> > > +    }
> > > 
> > > eventually print a warning (while i've no idea what this condition implies, \
> > > like eg. a broken setup. It could be a bug in CFStringRef or CFLocaleGetValue \
> > > or either isn't re-entrant or whatever)
> > 
> > That is undoubtedly worth doing, but might not solve the whole problem.
> > See my reply to Luigi.  Briefly, this is where the crash was in the only
> > backtrace we have ever had. There might be other crash-points.
> That will then expose and be fixable =)

True. But the MacPorts people will not welcome further meinproc4 crashes.

> Of course altering the build script to not fail but write a "foobar.docbook.failed" \
> warning (that ideally contains a coredump) would be a workaround to harden the \
> process.

So that is doable, then?  I do not know how to go about it, being self-taught in C++
and not an expert on KDE, Qt and CMake.  Can you help, Thomas?

> (i've no insight into docbook creation - i google anyway ;-)

Well, that is news to me. I never knew before that all the KDE Handbooks are
on the web now. What about translations?

Maybe all we need in MacPorts is a note about this whenever a KDE app is
installed. We already have notes about setting up DBus.

> > > And no, forking the application seems the worst option (remember Ian, you'd \
> > > have to maintain that fork ;-)
> > 
> > Not in my philosophy, Horatio … :-)
> > 
> > Of course, if I made such a change I would take responsibility for it for as long \
> > as I am able, but what then?  I am getting rather old now …
> > 
> > In my philosophy, also in the salaried part of the computer industry and FAIK in \
> > free products like Firefox, maintenance is a *group* responsibility. 
> 
> Thanks for the lesson, but as German, let me be the Mephisto:
> 
> That is certainly right.
> How many able mac developers are there in the group of interested people right now, \
> again?

Sorry, I did not mean to preach.

I am just sad to think that all the work I have done on KGoldrunner, Palapeli,
KSudoku, Kubrick and KJumpingCube might go on the scrapheap when I can no
longer maintain it.  It was sad enough to see all the games and other KDE apps
that got junked when Qt 4 and KDE 4 came in.

Glooms, Ian W. … :-)


> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]