Package: libglib2.0-dev
Version: 2.28.4-1
Severity: normal

If you include Qt headers before this glib header, Qt's definition of "signals"
to "protected" (for moc) causes an error at line 151.  This is causing a build
failure in polkit-qt-1 (see #614436).

How is this a GLib bug and not a Qt one?

reassign 622176 libqt4-dev
thanks

AFAIK signals is not a reserved keyword in any standard, so IMHO the bug is in
Qt. It shouldn't define random stuff in public headers, but use something like
QT_SIGNALS or whatever (note the namespace). Also the convention is to use
uppercase for definitions, not lowercase.

Cheers,
Emilio

Sorry to take so long to respond to this...  In theory, you're probably
correct.  However, the "signals," "slots" and "emit" definitions are a
fundamental part of Qt programming that have been there at least since I
started working with Qt back in the Qt 3 days.  It would be a major change and
break probably 90% or more of Qt-using programs to disable or rename those
definitions.

Looking at the headers, I see there is a QT_NO_KEYWORDS option which keeps
only the Q_SIGNALS, etc. versions of the defines.  So I guess polkit-qt-1 could
be rewritten to #define QT_NO_KEYWORDS and update the source accordingly.  But
I'm not sure how that would impact packages using polkit-qt-1 (notably
including kde4libs).

Yup. the signals, slots and emit words are very common across Qt sourcecode.
There is also the Q_SIGNALS, Q_SLOTS , Q_EMIT, Q_FOREACH and other such
keywords.

It has happened upstream that it now builds with QT_NO_KEYWORDS, and I'm
trying my best to advice people to use the Q_version of the 'keywords'.

/Sune

-- 
Greeting,

I have access to very vital information that can be used to
move huge amounts of money.

If it was possible for me to do it alone I would not
have bothered contacting you. Ultimately I need you to play an
important role in the completion of this business transaction.

Regards,
Mr Alexander Bulyanda